Does anybody know how to find all maven system properties?
If I do mvn --help, I can see
-D,--define <arg> Define a system property
But no way to find an exhaustive list of those properties on internet.
Thank you for your help.
It would be great to have such a list, but the available / recognized properties are in the hands of plugin authors and there is no global registry. They may even change between plugin versions. However, they usually are part of the plugin documentation.
Some commonly used Maven properties:
maven.compiler.source
maven.compiler.target
maven.compiler.testSource
maven.compiler.testTarget
project.build.sourceEncoding
project.reporting.outputEncoding
maven.javadoc.skip
maven.test.skip
Furthermore, you can define your own property and use it anywhere in your pom.xml file via ${my.custom.property}.
Links:
https://maven.apache.org/pom.html#properties
http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
https://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html
Related
When configuring the Surefire Maven plugin for Quarkus, I have come accross the following in the doc
<maven.settings>${session.request.userSettingsFile.path}</maven.settings>
For my project I would also need to do the same thing for the settings-security.xml file because we use password encryption.
In Quarkus this can be done using
<settings.security>
I can define this with a project property in the pom.xml with the hard-coded path of the settings-security.xml file in my CI/CD environment (it is not the default one). But ideally I would like to extract it from the Maven execution environment using something similar to ${session.request.userSettingsFile.path}
I have 2 questions (I still have a very limited experience of Maven for the moment, so please bear with me)
I have found plenty of examples with the ${session.request.userSettingsFile.path} property, but no documentation. Anyone know where these properties are documented? It is not at all clear to me where they come from.
Is there an equivalent to ${session.request.userSettingsFile.path} for the settings-security.xml file, or do I have to define the path in the project properties?
Thanks
As we know there is a very useful option in Maven Resource plugin: we can use filtering to replace the placeholders in some resources files with some predefined values. The explanation can be found here: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
A question is: is it possible to use a conditional filtering? I.e. I want to replace some placeholders in my files but I want to do it basing on some conditions, for example:
if the value of myProperty = "DevelopmentSetup" then the replacement
comes from development.properties, otherwise use "ProductionSetup".
Can I do it with Maven?
While you cannot configure Maven's resource plugin to use conditional filtering (at least as far as I know), it is still possible with Maven to select a build profile based on the value of a particular property. As described on Maven - Introduction to build profiles, you can activate a particular profile when some property has a given value (scroll down to 'The profile below will activate the profile when the system property "debug" is specified with any value').
So, the solution to your problem would be to set up two profiles, development and production. In these profiles, you configure your resource filter settings accordingly to either use your development property file or production property file.
There is also some useful information in Maven: The Complete Reference. Especially the tips and tricks section.
I'm a little confused by the Maven documentation - should lifecycles be defined in lifecycles.xml or lifecycle.xml? Even the Sonatype reference talks about these two names seemingly interchangeably!
Still confused about components.xml too - if there's any good reference for that can you post it please?
Thanks,
-Dave
It should be lifecycle.xml (see Lifecycle Mappings):
Configuration of custom lifecycle mappings for the plugin, as generally stored in META-INF/maven/lifecycle.xml in a plugin's jar artifact.
lifecycles.xml, with an 's', appears only once in the Maven source, commented out as a distinct and never-used file.
Also, components.xml, as in Overriding the Default Lifecycle:
In your plugin project, create a META-INF/plexus/components.xml under src/main/resources.
See Creating a new phase for a full example.
I have the following property in Maven and I cannot find any information about it:
<properties>
<!-- development mode (exclude in production) -->
<exclude.bootstrap>true</exclude.bootstrap>
</propertes/>
Thanks for pointing me to the right documentation.
I haven't seen something like this before. IMHO this is just a regular, your own (or POM's author) property, probably used somewhere in this POM or its modules. There is an option that this is a special property, maybe related to some of declared plugins, but - as I said - I haven't used a plugin that uses this.
We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.