Apache Maven: Collaborative Mastery

Maven is a power tool for Java developers. However, harnessing Maven's incredible capabilities efficiently is no small feat. In this session, we’ll embark on a journey to decipher the complexities of Maven, offering solutions for developers of all levels within a team.

We start by demystifying the inner workings of Maven lifecycles, ensuring that newcomers and seasoned developers alike can navigate its intricate processes. We’ll delve into the intricacies of dependency resolution, providing clarity on this critical aspect of Maven.

We’ll also explore how a Maven Project Object Model (POM) seamlessly integrates with IntelliJ IDEA, making life easier for developers. Discover the ins and outs of upgrading Java versions within a POM and learn how IntelliJ IDEA assists in tracking and managing changes to dependencies, ensuring you stay on top of any vulnerability concerns.

As a bonus, we’ll share valuable collaboration tips and tricks specifically tailored for teams using Maven in IntelliJ IDEA. Whether you're a Java novice or a seasoned pro, this session is your guide to a smoother and more productive journey with Maven in a team environment.

Speaker: Chandra Guntur

Join us:


#maventutorial #mavenlifecycle #dependencymanagement

[khmarbaise]

The statement about you can write a pom file in yaml, json or alike is unfortunately wrong. The polyglot maven project (it uses an extension) supports that in a way but Apache Maven itself is strictly XML (apart from that it's not very widely used)...The usage of profiles should reduced to an absolute minimum. The default in Java projects is to have zero profiles. In particular for environment based things which violates 12-factor app..
The slide about the effective contains some issues... The effective pom (contains only profiles if you have used/defined some in your pom file) resolves bom things in dependencyManagement but It does NOT contain all dependencies including their transitive only the dependencies. Also the dependency conflict resolution can not be in there because they are solved during the build time. The possible conflicts can be shown by "mvn dependency:tree -Dverbose" About the subject BOM's if you import a BOM in your dependencyManagement (scope:import; type:pom) you never get things like plugins/pluginManagement only the dependencyManagement part of that BOM...and there is no inheritance relationship in any way... it's exactly a composition instead.The given example of the spring framework bom contains only a dependencyManagement part there is no plugins definition in there... The execution of "post-clean" phase can simply being achieved by using "mvn post-clean"... if you use a colon in there you will call a plugin goal instead...apart from that "mvn clean:post-clean" will result in an error, because it's trying to execute the goal "post-clean" of the "maven-clean-plugin"... Also the "default phase" does not really exist, because it's just a practice to use those phases like "clean" or "site" but you can call whichever phase you like...
The clean life cycle will execute two phases first "pre-clean" and afterwards "clean" (if you use "mvn clean")... but there is no plugin bound to the "pre-clean" phase it will not do anything...
The order of building of modules (in a so called multi module build which is a project which has parent/child relationship; In your model where the modules inherit from the aggregator) is defined by it's dependencies to each other (topologically ordered)...and Maven will do that automatically. never rely on manually defined orders! The environment setup for Maven contains "M2_HOME" which is simply not needed only the entry in "PATH" is required (JAVA_HOME could be setup by using sdkman.io or alike)...

[ApplyIT]

Many things about maven were covered. Must watch before working with Spring Boot or Android development with Maven as build tool.