intermediate-mvn

Walk through of Udemy tutorial: Java/Apache Maven: The Truth About Building Java Programs, and other hands on try-outs.

 

Some Learning Notes

About invalid target release error

• The root cause of the problem is that you have specified a higher Java version for Maven compiler plugin than what Maven knows in your system.
• A simple solution to this problem is either to reduce your target version in pom.xml
• or install a new Java version if you want to build your project in a higher version.
• the key to solving this problem is knowing that Maven picks the Java version from the JAVA_HOME variable and not from the PATH environment variable.  

Non-transitive Scopes

• provided and test
• A has dependency on juit. Junit's scope is test. X has dependency on A.
  X will not import junit due to A.
• Library has a non-transitive scope dependency, whoever imports the library will not import the dependency.  

Project Inheritance

• Most elements from the parent POM are inherited by its children, including:

  • scm
  • properties
  • repositories
  • build
  • reporting
  • profiles

• Notable elements which are not inherited include:

  • artifactId
  • name
  • prerequisites  

dependencyManagement

• Benefits of dependencyManagement: Different children can inherit only what they need.  

Project Aggregation

• Project Aggregation is not Project Inheritance.
• To achieve project aggregation, module name = artifactId = directory name
• Benefits of Project Aggregation: mvn commands that run on parent will be run on children as well.  

Project Inheritance Plus Project Aggregation

• Benefits:
  • Avoid redundancy with inheritance
  • Mvn run on parent only  

Project Inheritance V.S Project Aggregation

• A POM project may be inherited from, but does not necessarily have any modules that it aggregates.
• Conversely, a POM project may aggregate projects that do not inherit from it.  

packaging type

• Packaging types define the goals bound to a set of lifecycle stages.
  For example, if packaging is jar, then the package phase will execute the jar:jar goal.
• Default packaging type is jar.
• The packaging type required to be pom for parent and aggregation (multi-module) projects.  

Plugins

• Recommend to always run clean plugin before default/build lifecycle. To make sure all old stuff is cleaned up and will not affect the new builds.
• The binding between goal and phase is known as an execution, which are usually given a meaningful identifier.
• <id></id> exists only for you to be able to distinguish between other executions.
• If the plugin isn't bound to a specific phase (process-resources, package, install, etc) your execution will not performed.
  The plugin's documentation should tell if this is the case.
• Goals are either triggered:
  • Automatically (implicitly by their default phase or explicitly defined in pom)
  • By command line execution: mvn <plugin name>:<goal>
  • this is the answer for this StackOverflow question.
• Plugins are executed in order.  

? Where are plugins stored?

• In local repository as well.
• Just that it is not there in the 'External Libraries'.  

? Where are plugins inherited from?

• In Super POM there are no default plugins defined.
• Why in a sample effective pom we can see all default plugins?
• They are built in maven: A Build Phase is Made Up of Plugin Goals  

How to override Parent in Children?

• Parent: No <dependencyManagement> and no properties: Need to state specific dependency fully.
• Parent: No <dependencyManagement> but with properties: Override properties in children.
• Parent: With <dependencyManagement> but no properties: Override by specifying version number.
• Parent: With <dependencyManagement> and with properties: Override properties in children.  

How to override GrandParent in Parent?

• GrandParent: With <dependencyManagement> but no properties: Override with dependency in dependencyManagement of Parent.
• GrandParent: With <dependencyManagement> and with properties: Override properties in Parent.  

Some Rules

• No, the property of <artifact.version> does not automatically resolve artifact version. It is just a placeholder.
• Yes, property can inherit from parent.
• <version> can be inherited from <dependencyManagement> : if version is defined in the <dependencyManagement> of parent, child no need to specify <version> in dependency.
• Maven will pick up the nearest property definition for substitution.
• dependencies: dependencies always imported.
  dependencyManagement: dependencies imported only when needed by children.
• In a most basic, non-inheritance project, having dependencyManagement only will not import the dependencies.  
• Inherited dependencies counted as first level.
• Can exclude inner dependencies layers in.
• A has dependencyManagement. A is used as a dependency library. dependencyManagement will not work.
  dependencyManagement is for inheritance use.
• Dependency libraries will use the final/resultant/effective versions as well.
• After overriding dependency library's dependency, library will pick up/use the new version and still work.

 

Useful links

• Introduction to the POM
• POM Reference
• Setting the -source and -target of the Java Compiler
• List of Built-in Lifecycle Bindings
• How to Fix Invalid Target Release: 1.7, 1.8, 1.9, or 1.10 Error in Maven Build
• Very good blogpost: Mastering Maven: Adding Plugins
• A list of popular and most commonly used plugins: mojohaus