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