I have a parent POM which defines maven-compiler-plugin definition/configuration under pluginManagement.plugins.plugin.
I have a multi-module project which has a requirement to re-define the configuration for their respective modules (e.g. moduleA, moduleB). Since the definitions are inherited can I be assured that configuration specific to moduleA, moduleB will be used while performing the build.
e.g. moduleA wants to use jdk 1.5 to compile and moduleB wants to use JDK 1.6 to compile.
How should this be defined in the POM files? Do I need to define anything in the parent POM or should I just define compiler-plugin with respective configurations on moduleA, moduleB.
You can simply just define the compiler plugin with its appropriate configuration part which you need. But don't define the version of the compiler plugin this is inherited via the pluginManagement part.
Related
I read on Java 9 Modularity book:
Dependencies are always put on the module path, even when dependency isn't modularized yet.
[...]
The most important changes made to Apache Maven for support of the Java module system are as follows:
Uses the modulepath during compilation
Supports a mix of explicit modules and automatic modules as dependencies
I'm looking at maven documentation and I cannot find this information anywhere.
Does maven by default add <dependencies> to the modulepath (only?) and if yes, after which maven version?
Also if the above is true is there a way to instruct maven to not use modulepath at all?
No, Maven puts dependencies to module path only for those Maven modules that have module descriptors (module-info.java). Non-modular Maven modules still put their dependencies to classpath.
You can run Maven with -X option to see exact command-line options that are passed to javac.
does it make sense to have a maven submodule (which doesn't have any submodules to itself) to have a pom packaging?
Is there any use of doing that at some instance?
If not does it mean that all my last level submodules should have a packaging which is not pom?
Typically, there is a certain lifecycle associated with the packaging, e.g. the "jar" packaging will run the maven-compiler-plugin during the "compile" phase, etc.
If you choose "pom", then there is a very limited default lifecycle - I guess only the the "install" and "deploy" plugins are bound to the respective phases. You could probably use it if you want to have more control over what happens in a build.
Typically, you only would use "pom" packaging for aggregator modules (those that have submodules).
For more details on packagings and the Maven lifecycle, you can refer to Maven: The Complete Reference - 4.2. Package-specific Lifecycles
As a real-world where I actually use "pom" packaging in a submodule:
In some projects, I have a submodule called "PROJECT-doc" which contains asciidoc documentation that I compile to HTML and PDF as part of the build. These modules have the "pom" packaging - there is no Java code to compile, no JAR to build, and no unit tests to run - just the documentation is built. I manually bind the "asciidoctor-maven-plugin" to the "generate-resources" and that's it.
I think the main question is the use of packaging pom in maven - this question was answered here: What is "pom" packaging in maven?
The short form is: yes, you shouldn't have a module without submodules that uses packaging pom.
I have a multi-module project looks like this:
module-A
--POM.xml
--sourceDirectory
--SourceA.java
--testSourceDirectory
--testSourceA.java
module-B
--POM.xml
--sourceDirectory
--SourceB.java
--testSourceDirectory
--testSourceB.java
...many similar modules
ParentModule
--POM.xml
--dependency
--module-A
--module-B
...
--module-x
I have ParentModule in order to access the source files (SourceA.java) in A,B, etc. in Netbeans using "Go to type" without opening all the modules as projects. But it seems with the simple dependency I cannot access the testsourcedirectory sources (testSourceA.java).
Is there any tags that would allow my ParentModule to see and index all the testSourceDirectories in the modules?
I think you got something fundamentally wrong. Maven is a build tool ‐ see Maven's Introduction. It's not a tool for supporting the handling of your sources in the IDE of your choice.
Furthermore, a dependency, as declared in Maven, is a module/artifact/library your code relies on at runtime. So, there's no point declaring your test sources, which are used as part of the development cycle only, as (runtime) dependencies.
Could somebody explain to me, what are are differences between the file pom.xml and the file effective pom.xml in an apache maven project?
The Super POM
All Maven project POMs extend the Super POM, which defines a set of defaults shared by all projects.
The Simplest POM
All Maven POMs inherit defaults from the Super POM. If you are just writing a simple project that produces a JAR from some source in src/main/java, want to run your JUnit tests in src/test/java, and want to build a project site using mvn site, you don’t have to customize anything. All you would need, in this case, is the simplest possible POM shown in The Simplest POM. This POM defines a groupId, artifactId, and version: the three required coordinates for every project.
The Effective POM
It is the merge between The Super POM and the POM from The Simplest POM.
NOTE: This info was extracted from the following link (in the link the explanation is very complete)
Maven: The Complete Reference - 3.2. The POM
You can see the difference of a pom.xml and the effective pom.xml using
mvn help:effective-pom
which is describe here.
In a multi module project you'll use a parent pom.xml for defining general settings for all modules and then in each module there will only be specific settings.
The above goal will help you analyze the resulting pom that you could of course actually use instead of the parent reference.
The whole idea is by using the generalization (super-pom) / specialization (module pom) approach there is a central place where you can specify the general configuration. This is much more efficient then having to cut&paste the general parts.
Please also note that the effective pom will add the default behavior e.g. for the jar plugin so that you can debug issues like
Maven JAR Plugin 3.0.2 Error: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them
with this approach. See also Maven `help:effective-pom` only generating for a single project, not all projects
I have a multi project in maven like this:
paren-project
-> plugin-project
-> testbed-project
The plugin project generates a JAR, which is manually copied to a specific subdirectory of testbed (using whatever embedded script like groovy or ant). The important point: I don't want the plugin JAR to be in the classpath of testbed.
But I cannot found the solution to force the plugin project to be build BEFORE the testbed project. If I set the plugin project as dependency of the testbed project, it is added in the classpath.
Any solution, or do I have to switch to a build system like gradle, ivy or ant ?
As it is mentioned at the http://maven.apache.org/guides/mini/guide-multiple-modules.html
Reactor Sorting
Because modules within a multi-module build can depend on each other,
it is important that The reactor sorts all the projects in a way that
guarantees any project is built before it is required.
The following relationships are honoured when sorting projects:
project dependency on another module in the build
plugin declaration where the plugin is another modules in the build
plugin dependency on another module in the build
build extension declaration on another module in the build
the order declared in the modules element (if no other rule applies)
Note that only "instantiated" references are used - dependencyManagement
and pluginManagement elements will not cause a change to the reactor sort order
Maven is a versatile system. No need to switch.
You can add the dependency like this:
<dependency>
<groupId>group</groupId>
<artifactId>artifact</artifactId>
<optional>true</optional>
</dependency>
This way, the dependency will not be included in the classpath.
Read more about Optional Dependency