Re: mvn deploy without rebuilding?

[Jörg Schaible]

thully wrote:

> We can run mvn deploy whenever we make an RC build - however, the problem
> with that ends up being that we are deploying artifacts to our repository
> that may not be the final release. That's what we want to avoid - while we
> can re-deploy if we end up doing a second RC, the lack of version
> differentiation ends up being confusing (and possibly causes problems for
> anyone who has the old versions in their local repository)..

Use a third "staging" repository. If the release is approved, move it over 
to release repo. That's what Nexus does by default.

Cheers,
Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: mvn deploy without rebuilding?

[thully]

Our issue isn't with deploying some artifacts prematurely when an install
fails - that's not normally a problem, since we've generally done at least
one successful mvn install before doing an mvn deploy. 

The issue is that when we're in RC phase, we want to give our artifacts
version numbers as if they were a release (i.e. 3.4.0), as we want to
release that code byte-for-byte if no issues arise. However, as there is no
way to mvn deploy without rebuilding, we have to deploy these during the RC
phase. That is undesirable, as it means that we have "release" artifacts in
our repository that are not in fact releases... That's why we wanted to be
able to deploy the last build rather than doing it in one step...



--
View this message in context: 
http://maven.40175.n5.nabble.com/mvn-deploy-without-rebuilding-tp5866812p5867054.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

Re: mvn deploy without rebuilding?

[jieryn]

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
 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  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

Re: mvn deploy without rebuilding?

[Stephen Connolly]

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  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 >
> 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
> 
> > >
> > >
> >
>


-- 
Sent from my phone

Re: mvn deploy without rebuilding?

[Mirko Friedenhagen]

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  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
> >
> >
>

Re: An idea I had for one way of doing Continuous Delivery with Maven

[Dan Tran]

Very promising, may need to do some scm provider work to support other SCM
like Perforce?

Thanks

-D

On Wed, May 4, 2016 at 12:20 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Here's an embryonic idea I had for doing Continuous Delivery with Maven
>
>
> https://www.cloudbees.com/blog/new-way-do-continuous-delivery-maven-and-jenkins-pipeline
>
> Probably needs a little fleshing out.
>
> -Stephen
>

An idea I had for one way of doing Continuous Delivery with Maven

[Stephen Connolly]

Here's an embryonic idea I had for doing Continuous Delivery with Maven

https://www.cloudbees.com/blog/new-way-do-continuous-delivery-maven-and-jenkins-pipeline

Probably needs a little fleshing out.

-Stephen

Re: mvn deploy without rebuilding?

[thully]

We can run mvn deploy whenever we make an RC build - however, the problem
with that ends up being that we are deploying artifacts to our repository
that may not be the final release. That's what we want to avoid - while we
can re-deploy if we end up doing a second RC, the lack of version
differentiation ends up being confusing (and possibly causes problems for
anyone who has the old versions in their local repository)..





--
View this message in context: 
http://maven.40175.n5.nabble.com/mvn-deploy-without-rebuilding-tp5866812p5867017.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