I think that if your SCM supports the options and your MRM supports staging
then you can get the workflow you want by basically making every build a
release build e.g.
mvn -DreleaseVersion=1.0.0.${BUILD_NUMBER} \
-DdevelopmentVersion=1.0.0.0-SNAPSHOT \
-DsuppressCommitBeforeTag=true \
-DpushChanges=false \
-DlocalCheckout=true \
-DpreparationGoals=initialize \
release:prepare \
release:perform && git push --tags
That should basically just create the tag and build from the tag and then
only push the tag upstream if the release is successful.
The developers pom stays on 1.0-SNAPSHOT (but as we do not push commits
back to master it doesn't matter) and the release versions get their
version number from Jenkins.
On 2 May 2016 at 19:08, thully <tmh...@eng.ucsd.edu> wrote:
> Hi,
>
> Our project has many Maven artifacts, the vast majority of which are OSGi
> bundles. These bundles are distributed together as part of our application
> (Cytoscape), but may also be used by third-party developers using our API.
>
> Given this, we have been deploying our artifacts to a Maven repository each
> time we make a new release of our application. However, we've run into an
> issue with this - every time we run mvn deploy, the bundles are rebuilt
> with
> new time-stamps and checksums. This makes it impossible to ensure that
> what's in the Maven repository matches a tested release version of the code
> unless we deploy when we build (suboptimal when we have code we're not sure
> is release-ready, but has non-SNAPSHOT version numbers in preparation for
> release).
>
> I've seen that mvn deploy:deploy supposedly should do what we want (deploy
> without rebuilding). However, this fails on every one of our bundles with
> an
> error like the following:
>
> "The packaging for this project did not assign a file to the build
> artifact."
>
> mvn deploy:deploy-file works, but has to be done a file at a time with each
> POM and artifact specified on the command line. That would be a pain with
> 100+ artifacts/POMs in different locations. Does anybody know of a better
> way to do this?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/mvn-deploy-without-rebuilding-tp5866812.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
