I had an experiment plugin that would capture all the attached artifacts
and record them in an on-disk file. Then in another maven session you could
attach them back again. There were some bugs but it seemed promising
On Wednesday 4 May 2016, Mirko Friedenhagen <mfriedenha...@gmail.com> wrote:
> 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 <javascript:;>>:
>
> > 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 <javascript:;>>
> 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
> <javascript:;>
> > > For additional commands, e-mail: users-h...@maven.apache.org
> <javascript:;>
> > >
> > >
> >
>
--
Sent from my phone
