I have following not pretty structured pom:
...
<groupId>xxx</groupId>
<artifactId>yyy</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>pom</packaging>
...
<properties>
<xxx.yyy.version>0.1-SNAPSHOT</xxx.yyy.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>xxx</groupId>
<artifactId>aaa</artifactId>
<version>${xxx.yyy.version}</version>
</dependency>
...
</dependencies>
</dependencyManagement>
mvn release:prepare successfully changes version of pom and value of xxx.yyy.version property to specified in cmd release version(e.g. 0.1) - it is good, ok. After, pugin set-up new development version of project (e.g. 0.2-SNAPSHOT) - thats where I got problem: Value of xxx.yyy.version property remains 0.1. Why xxx.yyy.version property not changes to specified new development version 0.2-SNAPSHOT? How to fix it? Thnx in advance
Serious answer: consider using Maven Version Numbers Plugin instead. I've never heard anything good about Release Plugin (at least, I've heard lots of stories like yours).
make sure updateWorkingCopyVersions parameter isn't sets to be false (default true) in maven-release-plugin configuration.
when this param sets to be false versions wont be incremented
Related
Hi Meier I have used the following goal:
mvn versions:update-property
-Dproperty="emom.web.dependency.shr.version"
-Dincludes:org.safeway.com:emom-shr
-DgenerateBackupPoms=false
-DallowIncrementalVersios=true
-DallowSnapshots=true
clean package
My Job B pom.xml is:
<dependency>
<groupId>com.safeway.app</groupId>
<artifactId>emom-shr</artifactId>
<version>${emom.web.dependency.shr.version}</version>
</dependency>
Under the properties it has the version hard-coded:
<emom.web.dependency.shr.version>19.6.5-SNAPSHOT</emom.web.dependency.shr.version>
My Job A pom.xml:
<groupId>com.safeway.app</groupId>
<artifactId>emom-shr</artifactId>
<version>20.1.0-SNAPSHOT</version>
<packaging>jar</packaging>
When I run the above goal, Maven is picking the latest version (i.e. 20.1.0) from Artifactory but when I check the pom.xml of Job B under properties it still says 19.6.5. I need a way to change the 19.6.5 or current version to latest version available. Am I doing something wrong? I'm not able to figure it out.
Here's an example of versions-maven-plugin:update-property working in practice. I've used the common Mockito library as an example that works for everyone as it's in Maven Central.
Starting with this POM (noting the mockito-version property):
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>abc</groupId>
<artifactId>def</artifactId>
<version>0.0.1-SNAPSHOT</version>
<properties>
<mockito-version>2.22.0</mockito-version>
</properties>
<dependencies>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>${mockito-version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
The simplest way to upgrade it to the latest release version is this:
mvn versions:update-property -Dproperty=mockito-version
Replace mockito-version with emom.web.dependency.shr.version in your case.
You can then start to use more of the goal options to adjust the options. For example, you might:
Permit snapshots, not just releases, with -DallowSnapshots=true.
Disallow major version updates (i.e. third element from the right) with -DallowMajorUpdates=false. Note that the logic around these version number sections seems a bit flaky in the plugin - or isn't how I expect.
Avoid creating backup POMs with -DgenerateBackupPoms=false. This is cleaner, but if you omit this option then you can use mvn versions:revert to get yourself back to where you started.
To apply this to your scenario, I think you need to:
Check you've not got typos in your actual command (like you have in the question and comments).
Get rid of options that don't appear in the options.
Probably, keep things simple by not trying to run this in conjunction with anything else (unless it's in automation), so get rid of the clean package at the end of the command.
I'm trying to use maven to update to latest minor versions using maven-versions-plugin. The goal use-latest-versions has a flag allowMajorUpdates. But this will set the versions directly in the dependency.
mvn versions:use-latest-versions -DallowMajorUpdates=false
Where I'm located they store version numbers in the properties section of the pom.xml. And they want to keep it that way.
<properties>
<!-- This should be updated to 1.3, even if 2.0 exists -->
<an-app-version>1.2</an-app-version>
</properties>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>an-app</artifactId>
<version>${an-app-version}</version>
</dependency>
</dependencies>
The update-properties goal updates the properties like I want, but I don't want to allow major updates.
mvn versions:update-properties
I'm using maven 3.3.9. Any suggestions?
I'm using the versions plugin to update the dependencies to my projects, where the versions are defined in properties, e.g:
<properties>
<version.property>1.6-SNAPSHOT</version.property>
</properties>
<dependencies>
<dependency>
<groupId>com.foo.bar</groupId>
<artifactId>myProject</artifactId>
<version>${version.property}</version>
</dependency>
</dependencies>
Now versions:update-properties is doing a good job here, but for one situation. Lets say the version.property is set to the latest snapshot version available in my repo: 1.6-SNAPSHOT.
I would expect from the following command, that the version changes to 1.5
mvn versions:update-properties
But it stays on the latest snapshot.. Now what I'm missing here? The docs claims:
...executing the update-properties goal will update the version.property property to the latest common version available in your local repository and all currently active remote repositories
The parameter allowSnapshots is false by default. So, whats going on?
Why the version isn't updating to the latest release, which is 1.5? How can I do this?
I have all these version numbers throughout parent pom and children poms including the parent reference like so
<parent>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-core</artifactId>
<version>${parent.version}</version>
</parent>
and dependency references to other child projects like so
<dependency>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-shared</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
and finally the declaration of the version of the thing we are building
<modelVersion>4.0.0</modelVersion>
<groupId>com.company</groupId>
<artifactId>artifcat</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>ifp-shared</name>
<url>http://maven.apache.org</url>
EDIT based on some answers which solved half the question...
We want to have all the versions be ${project.version} since it is really just one project with one release number.
I can seem to do ${project.version} in the dependency but this does not work in the parent xml code above. Is there another way? (man, I should really just switch to gradle).
thanks,
Dean
<parent>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-core</artifactId>
<version>1.2.3-SNAPSHOT</version> <!-- real version-->
</parent>
<artifactId>blah</artifactId>
<!-- No version here, will be inherited -->
<dependency>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-shared</artifactId>
<version>${project.version}</version>
</dependency>
project.version is what you want. Not parent.version.
You need to use dependencyManagement tag to centerilize the versions in the parent pom for the dependencies.
See this question and answers
differences between dependencymanagement and dependencies in maven
For you your own modules, some of the properties are inherited from the parent pom. You will need to declare the parent version in each child but you don't need to declare a groupId/version in your child poms if you want them to be same as their parent's.
We switched to gradle which works fabulously now. Every automated build a new version is released as 1.2.x where x is the next build number. Downstream, projects depend on 1.2.+. This allows every release to be official so QA can test it, reject it or go, yup, build 1.2.568 is the release we will release to the world. Projects can depend on 1.2. but then they don't get bug fixes. This seems to work much better than all that snapshot nonsense as you give QA a snapshot and they approve and you have to change and do another build. We want every build to look official so they can release the one that happens to pass all QA tests.
is it possible to use the maven release plugin with a multi-module project, where some of the inter-module dependencies are specified using a parameter from the parent pom?
When I try to call release:prepare i get the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on project forest-parent: The version could not be updated: ${some.version} -> [Help 1]
Here is my plugin definition:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<goals>deploy</goals>
<tagBase>https://svn.domain.com/svn/project/tags</tagBase>
<autoVersionSubmodules>true</autoVersionSubmodules>
<tagNameFormat>#{project.version}</tagNameFormat>
</configuration>
</plugin>
Thanks in advance!
The plugin currently doesn't support parameterized versions from parent (tried v2.2.2 as well). The solution was to use {project.version}.
TL;DR: Accepted answer does not help; Known defect in maven-release-plugin; New CI-Friendly versions in maven 3.5 help somewhat (but don't really solve the OPs issue)
Long version:
The accepted answer doesn't work. I experimented and found the results commented by #Dormouse. Adding this answer for more clarification:
Prefixing the variable name with "project." gets maven release:prepare past the original error, but it will update the version of the custom-versioned module to match all the others
So, as #Dormouse states, the property is useless because after the first maven release call it will no longer refer to the correct version of the module.
For example - some excerpts from a demonstration:
parent pom.xml:
<version>1.0-SNAPSHOT</version>
<properties>
<!-- note the custom property starts with "project" to pass release:prepare -->
<project.version.custom>1.2-SNAPSHOT</project.version.custom>
</properties>
<modules>
<module>custom-versioned-module</module>
<module>dependent-module</module>
</modules
custom-versioned-module/pom.xml:
<parent>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>custom-versioned-module</artifactId>
<!-- this module has 1.2-SNAPSHOT instead of 1.0-SNAPSHOT like the rest -->
<version>1.2-SNAPSHOT</version>
dependent-module/pom.xml
<parent>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>dependent-module</artifactId>
<dependencies>
<dependency>
<artifactId>custom-versioned-module</artifactId>
<!-- experiment with variable version -->
<version>${project.version.custom}</version>
</dependency>
</dependencies>
Now try mvn release:prepare -DdryRun=true and examine the files created. (You can see what the release:perform would do by looking at pom.xml.next - this is used to replace pom.xml if you do not use -DdryRun)
You will see that the version property is left intact, as is the dependency (we wouldn't expect the maven-release-plugin to mess with those), but the actual version of custom-version-module is changed!
custom-versioned-module/pom.xml.next:
<parent>
<version>1.1-SNAPSHOT</version>
</parent>
<artifactId>custom-versioned-module</artifactId>
<version>1.1-SNAPSHOT</version>
The parent version is increased from 1.0 to 1.1, but the module version is decreased from 1.2 to 1.1 (it's simply made the same, not specifically decremented)
Meanwhile the property itself remains at 1.2 so if you actually release, the next build will fail.
Note that this is logged as maven defect here: https://issues.apache.org/jira/browse/MRELEASE-782
And it is somewhat mitigated by the CI-Friendly versioning in 3.5:
https://maven.apache.org/maven-ci-friendly.html