[
https://jira.codehaus.org/browse/MRELEASE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356360#comment-356360
]
Jackie Noi commented on MRELEASE-399:
-------------------------------------
This issue still exists with latest maven versions, so I solved the resolution
of the parent version during release via the maven-groovy-plugin by adding the
following code to the parent pom. This enables reproducible builds of released
versions while still using RELEASE as version of parent artifacts in trunk.
{code}
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<preparationGoals>clean org.codehaus.gmaven:groovy-maven-plugin:execute
verify</preparationGoals>
<completionGoals>org.codehaus.gmaven:groovy-maven-plugin:execute</completionGoals>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
<source><![CDATA[if(project.parent != null) {
def projectParentVersionRaw = "${project.parent.version}"
def projectParentVersionResolved = project.parent.version
def newParentVersion = null
if(project.version.endsWith("-SNAPSHOT")) {
// revert parent in next development snapshot POM before commit
if(projectParentVersionRaw != "RELEASE" && projectParentVersionRaw !=
"LATEST") {
def oldPomFile = new File(project.basedir, "pom.xml.releaseBackup")
if(oldPomFile.exists()) {
def oldPomRoot = groovy.xml.DOMBuilder.parse(new
FileReader(oldPomFile)).documentElement
use(groovy.xml.dom.DOMCategory) {
oldPomParentVersion = oldPomRoot.parent.version[0].text()
}
if(oldPomParentVersion == "RELEASE") {
newParentVersion = "RELEASE"
}
}
}
} else {
// set resolved parent version in release POM before commit
if(projectParentVersionRaw == "RELEASE") {
newParentVersion = projectParentVersionResolved
}
}
if(newParentVersion) {
log.info("Setting parent version to $project.parent.version")
def pomFile = new File(project.basedir, "pom.xml")
def pomRoot = groovy.xml.DOMBuilder.parse(new
FileReader(pomFile)).documentElement
use(groovy.xml.dom.DOMCategory) {
pomRoot.parent.version[0].value = newParentVersion
}
pomFile.write(groovy.xml.XmlUtil.serialize(pomRoot))
}
}]]></source>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.3.7</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
{code}
> Replace dependency version for <version>RELEASE</version> dependency.
> ---------------------------------------------------------------------
>
> Key: MRELEASE-399
> URL: https://jira.codehaus.org/browse/MRELEASE-399
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: prepare
> Affects Versions: 2.0-beta-8
> Reporter: Nicolas Adrian Barrera
>
> I 'm using RELEASE version for some dependencies in my current project.
> Imagine a simple scenario where i have project A who depends on project B...,
> A's pom.xml states:
> ...
> <dependency>
> <artifactId>b</artifactId>
> <groupId>ar.com.b</groupId>
> <version>RELEASE</version>
> </dependency>
> ...
> When running "mvn compile" to A, there maven knows which is B's last released
> version so that it can compile against certain specific code at that time,
> imagine it is 1.2.0.
> So why when I run "mvn release:prepare" A's tagged (released, svn cp) pom.xml
> doesn't replace <version>RELEASE</version> with <version>1.2.0</version> ?
> Why do i think it should?
> * So that A's released version will always work the same as that day I
> performed A's release
> * So that A's released version won't get hurted by possible
> non-backward-compatible changes on future B's releases
> I 've read at the Maven Definitive Guide e-book that use of
> <version>RELEASE</version> is not encouraged, but i seemed helpful for me
> until this point where I find this quite dissapointing.
> Please feel free to share thoughts may be I got confused with this but i
> think this is a problem that worth to be solved.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
