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.
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 working with ideaIC-2020.2.3
I am able two open two windows to open two different projects for each window respectively. These projects are based on Gradle, for example
Spring Framework
Spring Integration
About settings I am able to define the gradle user home location, but it is common for all the projects. I want to know (if is possible - by the IDE itself or through a special plugin) define for each Project a custom and isolated (or different) gradle user home location. I tried for each project do right clic and Open Module Settings and does not exist something to accomplish this goal.
Observation: in STS/Eclipse - for Maven is possible for example that for each workspace import a custom and different settings.xml file indicating a specific and different repository.
It is not possible. Please vote for IDEA-163506.
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
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.
I'm developing a plugin for Eclipse (4.2 on windows) that uses a bunch of external files (batch scripts, xml files, ecc).
I'm asking if there is a good method to manage those files inside the project in order to:
keep all the plugin resources inside the project for version control in SVN
possibly have an automated plugin installation (including those files outside the plugin jar)
Edit: Can an additional "Feature Project" be a solution?
Instead of having a project I would manage two: one for the plugin and one for the "feature" that references the plugin and gathers the non-plugin data.
In that case, I see that eclipse "Features" have an "installation" section (in "feature.xml"). How could I specify for each "non-plugin" file the install path location?
I'm using nested projects for this.
Create a parent project that will contain everything. For each sub-project, deactivate the default location when you create it and select the parent project's root folder instead.
Here is an example: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/
It doesn't have a .project file in the root but having one doesn't hurt.
Just remember to import the sub-projects before you start working on them. Otherwise, you and Eclipse might get confused.