In maven multi-module project can we have parent project to build/execute after child?
We have custom plugin in parent that needs to be executed after child modules are build. Is there any maven life cycle that says to execute plugin after child projects are build ?
Simple answer is: No, cause the parent is always executed first before any child. If your custom plugin needed to have all childs modules have been built you plugin should check this. Furthermore it has to be configured into a separate module which contains all other childs as dependencies to make sure the ordering is correct (Maven is doing this automatically).
And there is no such lifecycle cause the lifecycle is something about step by step but does not defined something about child/parent relationship...
Create a "deploy" module, define your plugin in that module's pom.xml and put this module at the end of modules list.
Related
I want to define a build in the parent pom to enforce that build to the children.
Ideally a child pom just does mvn install and applies the build defined at the parent level.
I have 2 problems:
The build makes use of properties that are defined only in children
When I do mvn install on the parent I just want to create the pom and save it on my maven repo, not actually do a build (that should be done in children)
Is it possible to store helper files inside of the parent pom to use them in the child?
Is this possible?
You can define pretty much in the parent POM.
You can define all the plugins in the pluginManagement. You can use the <plugins> section of the parent POM to activate the plugins without using them in the build of the POM itself (with <phase>none</phase> and <inherited>false</inherited> on the execution)
You can build the parent POM and put it in a repository.
You can predefine properties and let child POMs override them.
But you cannot add additional files.
4all who stumbled upon this question only now (like me):
in addition to the possibilities described in the previous answer, you could define profiles in parent project, but activate them only in concrete project, e.g. by overriding profile activation property. This way you can avoid execution of the stuff during the build of the parent.
you could even go further and workaround limitation of additional files (beware, this is evil*):
define helper module(s) in the repository of your parent project
add dependency to the helper module in the profile defined in parent project
unpack helper files using the maven-resources-plugin (copy-resources)
*) why this is evil? - well, if you need a hack like this, it is an indicator that something is wrong with your architecture. Otherwise, if this would be a common requirement, the Maven team would provide a proper way to handle it.
I need to extract a project from a repository which uses several layers of parent projects. Every parent project adds some dependency or plugins or properties. This is becoming a nightmare as I'm not able to build any more the project, once I've manually added pieces from parent projects.
Is there a way to create a list of all dependencies/plugins/properties which are linked by a single pom.xml so that I can build a portable, single Maven project?
Thanks
You can create the effective pom (https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html) that is a kind of merge with all parent POMs.
This is useful to understand the complete list and configuration of plugins.
Whether this helps you to build a "portable" Maven project, I don't know. Without the appropriate Maven repositories with all the plugins, dependencies and so on, Maven will not build.
Base concept of Maven is CoC (Convention over Configuration). Maven has a SuperPOM and all model is inherited from that. SuperPOM is located in maven-model-builder jar. Here is the source https://maven.apache.org/ref/3.6.2/maven-model-builder/super-pom.html
Each Maven goal is using a merged model called effective pom. The help plugin has effective-pom goal which displays the full model including parent model(s) and SuperPOM.
So the answer is just run: mvn help:effective-pom command to see actual model.
My question is relatively simple. I do have a project that has a typical parent pom with a dependency management and a module with a pom that "normaly" inherits those dependencies.
If I explicitly name the parent inside the inherited pom, then the project builds successfully, but if I omit the parent information then the project fails to build.
One would expect maven to be able to build this project normally since the aggregation pom lists all the modules along with the dependency management.
Why is that not the case?
Because you are mixing inheritance with aggregation.
In Maven, inheritance means declaring a parent POM for this POM (with the <parent> tag element). By default, each POM inherits from the Super POM. This inheritance allows to factor out common dependencies inside the parent (like plugins version or dependency management).
On the other hand, aggregation is a synonym for a multi-module project. This means that an aggregator project declares sub-modules (with the <module> tag element).
Even if it's not commonly used, you could have a project that aggregates sub-modules for which their parent is not this project. It is very common to see parent projects that are also aggregator project but it's not a necessity. So the build fails in your case because you reached the situation of an aggregator project that is not a parent project anymore so the sub-modules do not inherit from its configuration.
Quoting from the Maven docs:
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.
Further reading:
The Maven book: Multi-module vs. Inheritance (selected quote):
There is a difference between inheriting from a parent project and being managed by a multimodule project. A parent project is one that passes its values to its children. A multimodule project simply manages a group of other subprojects or modules. The multimodule relationship is defined from the topmost level downwards. When setting up a multimodule project, you are simply telling a project that its build should include the specified modules. Multimodule builds are to be used to group modules together in a single build. The parent-child relationship is defined from the leaf node upwards. The parent-child relationship deals more with the definition of a particular project. When you associate a child with its parent, you are telling Maven that a project’s POM is derived from another.
Maven documentaton: Project Inheritance vs Project Aggregation (selected quote):
If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.
I'm currently creating a parent pom and defining maven modules underneath it. With the current way I have Project view set up, It's placing the modules underneath the parent POM, and I have to drill down on them individually. Is there a way to have them in their own project so I don't have to drill down within each directory?
Thanks!
Go to
Settings -> Maven -> Importing
and play with these to find out what suits you.
Create IntelliJ IDEA modules for aggregator projects (with 'pom' packaging)
Create module groups for multi-module Maven projects
See http://www.jetbrains.com/idea/webhelp/maven-importing.html for details.
My (new) Gradle project depends on a Maven project that is a child of a parent Maven project with many subprojects. Notice that I only care about one little subproject there, nothing else from that parent.
Trouble is, Gradle walks up the Maven project tree and when it sees the "dependencyManagement" in parent pom instead of treating it for what it is - list of "approved versions" of dependencies for any and all subprojects of that parent, it actually assumes that they are ALL actual dependencies of the child/subproject I care about... And that brings waaaay too much stuff into my Gradle project.
I am presently working around by explicitly excluding all those dependencies I presently know are not presently (again) not needed, but I don't want to do that as that would mean that I have to keep up my project essentially in sync with ALL projects from that parent.
This is with Gradle 1.6. I MAY have some (little) level of influence on how those Maven projects are structured but preferably such a thing would not be needed and I could somehow tell Gradle to behave as it should... Is there a way?
Please help!
EDIT 1
The dependency is via a maven repository. The dependency I have is a subproject of a project built and deployed by Maven, to a Maven repository.
I also asked this on Gradle forums: http://forums.gradle.org/gradle/topics/8mftwmyn8uu75?rfm=1
Turns out this was not a problem at all. Huge POM of that parent project was hiding some actual dependencies that exploded...