Comments on: Tagging and branching with the Maven release plugin – a few pain points http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/ It's easy if you know how Tue, 18 Oct 2011 14:25:40 -0700 http://wordpress.org/?v=2.8.3 hourly 1 By: Baptiste http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/comment-page-1/#comment-1334 Baptiste Tue, 28 Apr 2009 20:41:19 +0000 http://blogs.plexibus.com/?p=4#comment-1334 <blockquote cite="Alex"> IMHO, there should be a setting to override this *Check that there are no SNAPSHOT dependencies* behavior. </blockquote> Well, I disagree with this one. I really think maven snapshot (and the release-plugin) handling is the right way to go. Depending on a snapshot version ad vitam æternam gives you the risk to make your build unreproducible in the future (using the created tag). IMO, the way to go in this particular case is the following (depending on snapshot version, because no other exists) : * Install and configure (if not already done) a maven repository manager (archiva, nexus, artifactory... choose what you want) * retrieve the corresponding jar/last version known to work with your code * deploy it as a released version (deploy:deploy-file goal) * use this jar as the dependency for the project you're releasing. HTH, Cheers

IMHO, there should be a setting to override this *Check that there are no SNAPSHOT dependencies* behavior.

Well, I disagree with this one. I really think maven snapshot (and the release-plugin) handling is the right way to go.

Depending on a snapshot version ad vitam æternam gives you the risk to make your build unreproducible in the future (using the created tag).

IMO, the way to go in this particular case is the following (depending on snapshot version, because no other exists) :
* Install and configure (if not already done) a maven repository manager (archiva, nexus, artifactory… choose what you want)
* retrieve the corresponding jar/last version known to work with your code
* deploy it as a released version (deploy:deploy-file goal)
* use this jar as the dependency for the project you’re releasing.

HTH,
Cheers

]]> By: Alex http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/comment-page-1/#comment-54 Alex Fri, 29 Feb 2008 14:24:49 +0000 http://blogs.plexibus.com/?p=4#comment-54 Doh...Should RTFM. Just found the doc. Doh…Should RTFM. Just found the doc.

]]> By: Alex http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/comment-page-1/#comment-53 Alex Fri, 29 Feb 2008 14:12:08 +0000 http://blogs.plexibus.com/?p=4#comment-53 Could you please post exactly how you override the default “preparationGoals” element of the Maven release plugin? I need to do the exact same thing. Thanks! Could you please post exactly how you override the default “preparationGoals” element of the Maven release plugin?

I need to do the exact same thing.

Thanks!

]]> By: Confluence: Anthony Whyte http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/comment-page-1/#comment-52 Confluence: Anthony Whyte Mon, 18 Feb 2008 05:08:01 +0000 http://blogs.plexibus.com/?p=4#comment-52 <strong>Maven Release Notes...</strong> # Configure the SCM in the base and master poms, specifying location of source code. Note that some projects also define in their parent poms (e.g., access, rwiki) while others do not. scm:svn:https://source.sakaipr...... Maven Release Notes…

# Configure the SCM in the base and master poms, specifying location of source code. Note that some projects also define in their parent poms (e.g., access, rwiki) while others do not. scm:svn:https://source.sakaipr……

]]>