Is there a way to activate a Maven profile only if a project is (or is not) being deployed?
nexus staging plugin deploys all modules that are part of a reactor build so I want to skip certain modules (unit tests, benchmarks, etc) if the project is being deployed (to deploying them).
I know I can invoke mvn -Ddeploy deploy and activate profiles based on the deploy property but I'm hoping there is a way to avoid mentioning deploy twice.
AFAIK, you cannot do that.
There is list of possible profile activations (https://maven.apache.org/guides/introduction/introduction-to-profiles.html), stating:
A profile can be triggered/activated in several ways:
Explicitly
Through Maven settings
Based on environment variables
OS settings
Present or missing files
My guess is that profiles are evaluated before the phases/goals are even read by Maven. I tried to figure it out from https://stackoverflow.com/a/14727072/927493, but it does not say it explicitly.
It may help, though, to set <skip>true</skip> for the deploy plugin in the respective modules (the property maven.deploy.skip could also be used).
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
Related
Suppose a team in the US has a project containing this local library
<dependency><artifactId>garbage</artifactId></dependency>
but the UK version of our project has a pom.xml with this dependency listed instead:
</dependency><artefactId>rubbish</artefactId><dependency>
which specifies the localised build of the artefact.
Currently, a script takes the garbage project, builds it with UK localisation, but then has to patch up the .jar files after the fact so that the artefactId reflects the localisation, including if the string has been copied as part of the build process. This method has proven to be unreliable, however: Is there a way of migrating to a system which uses Maven, alone, to change the build ID depending on something like the LANG environment variable?
Or; is it not possible to introduce configuration into the pom.xml configuration file itself?
If you need to build a project for different environments, you can use Maven Profiles:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
You can put different dependencies into different profiles and activate/deactivate the profiles in build process, on the command line or e.g. by marker files.
We have a maven based Java EE project controlled by the customer. For internal reasons, we cannot execute one of the build steps, but the rest works fine and produces the jar we want.
Since editing the pom file would require taking care when committing to customer's SVN and copying the pom file would require taking care to sync changes comming from there, we are looking for a way to skip this specific step in the build section during the maven call itself, so to say mvn clean install but-leave-out-this-build-plugin-step, is there any?
Edit:
The plugin in question is the rpm-maven-plugin, which prevents the build from running on Windows. We found information how to make it work which won't really fit in our current setup. And since we cannot modify the customer's pom, I was looking for a way to trigger the skipping externally. But maybe there are other ways to just ignore/skip/fake this step?
It depends on what plugin you want to skip. Many plugins have ability to be skipped via system property (-Dblabla).
For deploy plugin it is -Dmaven.deploy.skip=true, for surefire -DskipTests=true.
Read plugin documentation, maybe you can find skip property
The rpm plugin hase a property disabled, unfortunately it is not accessible by a property. So, if setting this property in the customer's pom (or asking for editing it) with a default value of false is an option, this may be the solution.
We are using a maven plugin that sets version properties. These properties are used in the POM files to create the file name of the War, EJB and EAR files - and used by Jenkins.
My problem is that when I import a maven project or re-import IntelliJ uses theses file names to generate artifacts, but the artifact names become weird because the properties are not generated on import (the plugin is not run).
The outermost / top pom has these props:
${parsedVersion.majorVersion}.${parsedVersion.minorVersion}
iqe-ws${parsedVersion.majorVersion}.${parsedVersion.minorVersion}
the EAR Pom file has this prop:
iqe-${parsedVersion.majorVersion}.${parsedVersion.minorVersion}
So the ear artifact file ends up with looking like:
iqe-${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.ear
If I hard code the Props - say 2 and 1 the it becomes
iqe-2.1.ear
There are a number of ways of dealing with this.
The best is to use profiles. Put the original version of the properties are in a profile that is used on the CI box, and a set with specific values are held in a profile that is used in your local environment. Profiles are activated on the CI box using the -P profile-name switch, and in IntelliJ by selecting the appropriate profile in the maven project's window. It may even be possible to activate the correct profile automatically depending on the existence of an environment property or OS.
Alternatively, you could just override the properties using a local settings.xml file, but this would be specific to you and harder to distribute to the team and to future developers, so it's not a great solution.
Here's a link to the maven profiles documentation.
I have a multimodule project. All of the modules, but one are different. There are some things in the settings.xml file that I want to be different in the one module than from the rest.
Is it possible to have two settings.xml file and use them for different modules?
Think of the settings.xml as the configuration for your installation of maven. It determines the behavior of maven across it's use in your various projects.
This being said, if an individual project, i.e. a pom, requires something unique, it should be in that pom.
I think the thing to remember is that the project should be able to build on an individual dev's machine without any special intervention. In other words, the ideal case is that a given pom can successufl execute mvn install in a vanilla environment. So, don't put something in it that requires tweaking for a dev to get it to work. Also don't put anything in your settings.xml that enables a project to build, but then puts the burden on other devs to know what secrets are in your settings.xml.
You can set up different things in your individual pom files. What's in the pom files will override what's in settings. For instance, if your child poms sets up different repositories they'll be used over what is defined in settings.xml. Settings.xml is the default is nothing else applies. Depending on exactly what you want to do you might also take a look at the profiles feature.
I started using JRebel just moment ago. In my current setup launch JBoss instance from Eclipse and I use command line maven to deploy. I was wondering whether it would be anyhow possible to avoid redeployment when I need to change from test-A profile to test-B profile. Profiles are used here to set several configuration values.
If you're using JRebel, you should forget about Maven as there's no need to build the package after every change.
If profiles are used only for configurations, why not to make the changes to the configuration files directly? Depending on the nature of the configuration files these can be handled by JRebel. What are those configuration files?
You can't change profiles for already running Maven instance. But you can activate specific profiles on Maven startup using system properties.