Hello,
what about enhancing the install plugin with a list of the latest installs
and creating a mojo deploy:deploy-latest-install?
Regards
Mirko
--
Sent from my mobile
Am 03.05.2016 18:15 schrieb "Stephen Connolly" <
stephen.alan.conno...@gmail.com>:
> 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
> >
> >
>
