[
https://issues.apache.org/jira/browse/MRELEASE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563129#comment-14563129
]
Robin Pradel commented on MRELEASE-399:
---------------------------------------
@[~jackienoi]: Thanks for your work.
I had some line ending issues within xml comment tags inside my pom (missing
carriage return character). There is also a misleading log output.
So here is my enhanced code based on Jackie's snippet:
{code}
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<!-- run groovy before commit to resolve keyword RELEASE -->
<preparationGoals>clean groovy:execute verify</preparationGoals>
<!-- run groovy to restore keyword RELEASE after release
build-->
<completionGoals>groovy: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 " + newParentVersion)
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
}
xmlBadEndings = groovy.xml.XmlUtil.serialize(pomRoot);
xmlLinuxEndings = xmlBadEndings.replaceAll(/\r?\n/,"\n")
ln = System.getProperty("line.separator")
xml = xmlLinuxEndings.replace("\n",ln)
pomFile.write(xml)
}
}]]>
</source>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.1</version>
</dependency>
</dependencies>
</plugin>
{code}
> Replace dependency version for <version>RELEASE</version> dependency.
> ---------------------------------------------------------------------
>
> Key: MRELEASE-399
> URL: https://issues.apache.org/jira/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.3.4#6332)
