The Maven documentation talks about a property called project.build.finalName, but I couldn't find a definition of the value it is set to based on other values in the pom.xml.
How is the value of project.build.finalName computed in absence of an overriding property definition in the pom.xml?
Google that...
Look at the Maven POM reference: http://maven.apache.org/pom.html#BaseBuild_Element
finalName: This is the name of the bundled project when it is finally
built (sans the file extension, for example: my-project-1.0.jar). It
defaults to ${artifactId}-${version}. The term "finalName" is kind of
a misnomer, however, as plugins that build the bundled project have
every right to ignore/modify this name (but they usually do not). For
example, if the maven-jar-plugin is configured to give a jar a
classifier of test, then the actual jar defined above will be built as
my-project-1.0-test.jar.
In the Eclipse Maven POM Editor, the "Effective POM" tab, you can see the value explicitly.
In the IntelliJ Idea, Right-click on the project top folder and then click Maven => Show Effective POM to view the effective pom file. In that file, search for "finalName" to know it.
The final value is composed of the artifact groupId concatenated to the artifact id that you have declared in your pom.xml file
Related
According to http://maven.apache.org/settings.html we have an example and explanation of all the elements.
But I want, for example, customize some build settings for ALL projects, not to be pushed in every project pom.xml.
Other people looking for this, too, but still no solution.
Maven ignoring build segment in settings.xml?
But, surprisingly, build tag is NOT available in settings.xml.
Is there a way to inject build parameters, like target dir into settings.xml using profiles, etc?
Two things:
The standard way is to create a company parent POM that is used as parent for all the projects. It can configure plugins and other build information.
If you want things be overridden by the settings.xml, use properties and then define the properties in the settings.xml.
I am moving from maven-bundle-plugin which provided the "convenient" configuration using Embed-Dependency, but it appears i need to specify my Embed Dependency "manually" in bnd format when using the bnd-maven-plugin. I added the same bundle headers from my old package, but it doesn't seem to be including the actual dependency's jar file. Does someone have a quick/concise how-to do this?
bnd has an instruction -includeresource defined here https://bnd.bndtools.org/instructions/includeresource.html:
Here's an example:
-includeresource: lib/somelib.jar=somelib-[\w.]*.jar;lib:=true
This should have visibility into all the dependencies in the classpath used to build the artifact and matches on the file name of the associated files.
[Update with BJ's comment]
The lib:=true will automatically add the jar to the bundle's Bundle-ClassPath header in a merge safe way (i.e. by making sure it plays nice with existing content or non-existent value).
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.
In Maven one can use the base pom file concept(https://www.atlassian.com/blog/archives/maven_in_our_development_proce_3) - the file everyone would then reuse
Is it a similar concept in Gradle? We use Gradle to build Java projects
You should take a look at this answer
Basically, the parent project can hold the role of "parent POM" and thanks to Gradle's allprojects, subprojects and extra properties mechanisms, you can reproduce Maven's main behavior. Also you can split your configuration in several .gradle files and include them with apply from. Finally, regular and custom plugins can be defined in the parent project, for target or all sub-projects.
I'm not talking about the Maven Properties Plugin, or resource filtering. I want Maven to replace properties in the POM itself. For example, let's say I have several POMs that reference a particular dependency's version number. I want to be able to load in one properties file for each of those POMs, and then change the values once. Maven would then read the properties file before processing the POM and replace accordingly. I believe this is how Ant does it in a single pass, and the properties are then immutable within the build.xml.
You can do property replacement on the command line if that fits your situation. I change the version of my project in the pom on the commandline (really through NAnt scripts). For example:
mvn deploy -Dproject.version=1.00.00.0-Something-SNAPSHOT
You mentioned you want to change a property that is within the parent tags. In maven 2 (not sure about maven 3) anything within the parent tags cannot be a property and must be the actual values. Maven doesn't evaluate properties with in the parent tags.
You are asking about a multi-module build which often comes to the point of the version number. But the simple answer for that is: Use the maven release plugin so you don't need to deal with the version numbers. Or you can use the versions-maven-plugin to handle modifications of them in an elegant way. And it's best practive not to use properties for versions of parents in pom's (onr that it will work as you described).