Seems like a lot of time fighting what Apache Maven does. Usually a
good smell that you're doing something wrong.
Use installAtEnd / deployAtEnd. Bytes are cheap, just burn them and
move on to a real problem.
On Wed, May 4, 2016 at 3:48 PM, 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>:
>
>> 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
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
