I am doing some re-factoring to use parent poms and put common configuration in a common place.
I have a separate git repo to house the parent poms. Some of the common configuration specifies directories/files that will exist relative to the child projects, but not relative to the parent pom (they are in different git repos).
When I try to deploy the pom, one of the plugins is failing because the path does not exist.
How is this supposed to work?
I'd expect that if the artifact has "pom" packaging then it wouldn't actually try to run the plugins (at least that is what I want). Or do the plugins I use need to be responsible for knowing that it is a "pom" artifact?
The parent should, probably, only have pluginManagement, not plugin.
The pluginManagement section of the parent pom is used to share plugin versioning and base configuration across modules. This is in line with the dependency management section of the parent, which allows you to configure versions and exclusions across modules. For example, you could configure the site plugin in the parent to provide a standard look and feel across all modules, while the modules override the site plugin with module specific details.
Related
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.
I have what I think is a fairly common setup. I have a project with two modules, each with its own pom.xml. Above that, I have a pom.xml for the project, which depends upon its submodules. The two submodules have a shared dependency, namely log4j. How should I deal with this dependency? Should I simply just have each submodule have log4j as a dependency, or should the higher level project module get involved, claiming it as a project dependency? If I have both submodules listing the dependency, will Maven be smart and only pull down log4j once, or will each submodule pull down its own private copy of log4j ? If the project module has the dependency, will the log4j package be available at the right time for the submodules? What would you do, or what have you done in this situation?
The best way to do this is with the dependencyManagement tag.
The dependency management section is a mechanism for centralizing dependency information. When you have a set of projects that inherits a common parent it's possible to put all information about the dependency in the common POM and have simpler references to the artifacts in the child POMs.
To summarize the effect, you put the tag in the parent pom and have the children refer to it. They don't refer to the version number though. The benefit is at any time you can update the version of log4j in the parent pom and all your child poms get the new version without modifying their poms.
You are able to set the dependency at the higher level project. This will cover the dependency for both modules of your project.
Source: This is what my team does in one of our projects.
Typically, a maven built jar artifact will have it's pom included under META-INF. I recently noticed that the Spring jars don't have this. So, that causes me to wonder about the purpose of that pom.
It seems like maven retrieves the pom directly from the repository when it's doing things that require knowledge of the artifacts meta-data, e.g. when determining dependencies.
So, what's the embedded one for?
The Maven docs suggest two reasons for the pom in this location.
1) Merely for reference, as a convenience. As the docs say, it makes the artifact "self describing"
2) You can get at this information from within your application using Java. This enables the arfiact to auto-report it's version within the application.
http://maven.apache.org/guides/getting-started/index.html
The pom you will find in the repository is not necessarily the one used to build the artifact. It is aimed at the users of the artifact and can be customized when building your artifact.
The one included inside the artifact IS the one used to produce the artifact.
There are options to not have it included in the artifact.
I am transitioning from using Buckminster to build an Eclipse product to Tycho. I've mavenized my plug-ins and features and have a question:
I created a parent feature with a POM that references my features and plugins. I don't know if I am doing this correctly, but I find that I need to add all features and plugins as modules. So if I have pluginA, pluginB and feature1 that includes pluginA and pluginB, I add all three to parent POM. This is a bit strange to me, because in Buckminster I had to reference only feature1 and it would get its dependencies based on the feature.xml file.
I am doing something wrong in my Tycho builds, or is this how it's suppose to work?
A Tycho build is driven by Maven, i.e. Maven first determines which modules should be part of the build reactor, and then Tycho builds the modules. Therefore, you'll need an aggregator POM that tells Maven about the list of artifacts to be built.
My Maven projects are multi-module and in general the version numbers are not synced. For instance, I can have a master POM versioned as 1.2.3-SNAPSHOT and a sub-module versioned 3.4.5-SNAPSHOT (the main reason for not keeping them synced is that often a module is moved from a project to another and it has to keep its version).
Now I want to put the main project version in a resource of the module containing the main (or the webapp, etc...), which of course is a sub-module. This means that I need to access the master pom version from a sub-module.
Also be aware that my projects have got 3 or 4 levels; thus the master pom is the grandfather of the submodule, not just the parent.
In spite of having some experience with Maven including advanced stuff, so far I've been unable to solve this problem.
Thanks.
It should work with ${project.parent.version}.