Given a pom.xml file, what would be a reliable way to determine the GAV of the parent?
At the moment, I am parsing the XML, but this means that terms like ${some.number} need to be resolved by hand.
Is there a Maven goal or an Aether method that determines the parent pom for a given pom.xml?
Related
When I analyse Maven dependencies with Aether, I often get objects of class
org.eclipse.aether.graph.Dependency
I want to extract all dependency information (as in the pom) from this object. This is easy for groupId, artifactId, version and classifier, because these are properties of the underlying artifact (using getArtifact()) The <type> is more difficult.
A dependency can have a type like <type>ejb</type>. I need to recover that type. The only related thing I found is getExtension(), but this is not quite the same, because artifacts of type ejb have extension jar.
Can anyone tell me how to find that type information?
My project and my parent pom both have a dependency management section. These sections both have direct entries and "imports" of boms (i.e. poms that purely consist of dependecyManagement and are imported). Now I try to figure out the evaluation order. My best guess:
parent pom imports
child pom imports
parent pom direct dependencyManagement entries
child pom direct dependencyManagement entries
This means that later elements overwrite earlier elements. Is this correct? If so, can I change this behaviour so that the child elements always overwrite the parent elements?
Following the ticket
issues.apache.org/jira/browse/MNG-5971
it is indeed true that direct management entries cannot be overwritten by imports in child projects. This behaviour should be altered in Maven 3.6.0, according to the statements in the ticket.
As Maven 3.6.0 is distant future, I have to work around this problem. I will probably avoid direct management entries in the parent pom by constructing an auxiliary bom.
I am new to maven and I'm confused about the difference between the artifactId and name.
What I know is that artifactId is the name of the artifact you are creating. I know that artifactId together with the groupId is use to uniquely identifies an artifact. So what is <name> purpose in POM. like the pom below I got from a site there is an artifactId and at the same time a <name>.
<groupId>org.sonatype.mavenbook.multi</groupId>
<artifactId>simple-parent</artifactId>
<packaging>pom</packaging>
<version>1.0</version>
<name>Multi Chapter Simple Parent Project</name>
You are correct that the artifactId helps identify the project.
The name is simply a human-readable "friendly" name. It is not required for a basic setup.
From the Maven documentation,
artifactId: The artifactId is generally the name that the project is known by. Although the groupId is important, people within the group will rarely mention the groupId in discussion ... It, along with the groupId, create a key that separates this project from every other project in the world (at least, it should :) ). Along with the groupId, the artifactId fully defines the artifact's living quarters within the repository.
The groupId, artifactId and version form a composite unique identifier (or coordinate) for this project. Each of these values has a fairly rigid naming convention that allows well organized groups, artifacts and versions.
The name is simply a readable name for the project and does not need to be unique or comply to the same conventions (so it can contain spaces and other characters).
The name is used for the project used by maven to build the artifact, while the artifact-id is used to identify the artifact that will be built.
For example:
This pom file definition for the rsts ear file:
Causes the rsts-ear project to be imported into Eclipse:
But creates the rsts_ear artifact in the nexus:
This means that the artifact-id, not the name, is referenced to include the artifact in the build as part of another artifact.
I am a newbie of Maven, currently reading Hadoop source code, and found something interesting in some pom.xml files:
Some of the dependency node do not contain version node at all.
Question: why is it like this?
for instance, this pom.xml.
Because specific version of dependency in parent pom.xml file
https://github.com/apache/hadoop/blob/trunk/pom.xml
Reference: https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
As I commented at first, a pom file can have a parent (via inheritance) and such a parent may provide some governance and harmonization across all of its children. A classic case is to provide versioning for certain dependencies via a dependencyManagement section.
is used by POMs to help manage dependency information across all of its children. If the my-parent project uses dependencyManagement to define a dependency on junit:junit:4.0, then POMs inheriting from this one can set their dependency giving the groupId=junit and artifactId=junit only, then Maven will fill in the version set by the parent. The benefits of this method are obvious. Dependency details can be set in one central location, which will propagate to all inheriting POMs.
The mentioned pom has indeed a parent pom:
<parent>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-project-dist</artifactId>
<version>3.0.0-SNAPSHOT</version>
<relativePath>../../hadoop-project-dist</relativePath>
</parent>
Which in chain has another parent pom file which defines several dependencies as part of its dependencies management section.
If you really want to check the effective (merged) pom your build is using, you could run:
mvn help:effective-pom -Doutput=effective-pom.xml
And the maven-help-plugin will produce an additional pom as specified by the command above, merging the current pom file and all of its anchestors.
In Maven you can inherit from parents folder in order to merge or inherit some properties. This can be the version of the modules. Usually you have a "super" POM in the root folder of your project and you put there all the commons dependencies in order to controll them in an easier way. I.e. If you must change one module version, you only need to change in the "super" POM and not in each POM inside each subfolder that need it. If you need more information about POM inheritance the documentation has a couple of useful examples.
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance
Expanding upon this question, if using a properties file in the dependency is the original question possible?
Usually you would do the following:
Create a pom-packaged project, using it as a parent pom
in this parent pom, read the property files you want to read using the Maven properties plugin by binding it's read-project-properties goal to the validate phase.
Refer to this parent pom in all the poms that shall share the properties read.