You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by thully <tm...@eng.ucsd.edu> on 2016/05/02 20:08:51 UTC
mvn deploy without rebuilding?
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: mvn deploy without rebuilding?
Posted by thully <tm...@eng.ucsd.edu>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: mvn deploy without rebuilding?
Posted by jieryn <ji...@gmail.com>.
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
<mf...@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.connolly@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 <tm...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: mvn deploy without rebuilding?
Posted by Stephen Connolly <st...@gmail.com>.
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 <mf...@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.connolly@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 <tmhull@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-unsubscribe@maven.apache.org
> <javascript:;>
> > > For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
> > >
> > >
> >
>
--
Sent from my phone
Re: mvn deploy without rebuilding?
Posted by Mirko Friedenhagen <mf...@gmail.com>.
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.connolly@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 <tm...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: mvn deploy without rebuilding?
Posted by Stephen Connolly <st...@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 <tm...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: [EXTERNAL] mvn deploy without rebuilding?
Posted by Justin Georgeson <JG...@lgc.com>.
The deploy and install plugins act on attached artifacts, which I believe generally requires the package phase. For a given packaging type, there should be a plugin goal which is by default bound to the package phase to creates and attaches the artifacts for the project. So for a standard single-artifact jar project you would need to run something like 'jar:jar deploy:deploy' and it will repackage and deploy the jar file. If you're using Tycho I think it would be 'tycho-packaging:package-plugin deploy:deploy'. However if you have secondary artifacts like configuring an extra execution of jar:jar during the package phase to create a modified jar (maybe without the OSGi manifest headers for example) then those will be missed by explicitly running the packaging and deploying goals like this.
I'd suggest that when you're building a release candidate you build with the deploy phase so that they're all deployed to a standard M2 repo pro-actively as part of the normal Maven lifecycle. If you're concerned about plugins having been deployed from projects low in the reactor only for the overall build to fail higher in the reactor, look at the deploy plugin's deployAtEnd feature which delays deploying until all projects in the reactor have otherwise succeeded.
Also you could maybe create a deploy-only profile that executes the build-helper-maven-plugin to attach already-built packaged files and then the deploy:deploy plugin goal, binding both to an early phase like initialize so it doesn't redo any code generation or compilation.
> -----Original Message-----
> From: thully [mailto:tmhull@eng.ucsd.edu]
> Sent: Monday, May 02, 2016 1:09 PM
> To: users@maven.apache.org
> Subject: [EXTERNAL] mvn deploy without rebuilding?
>
> 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
> 100+ better
> way to do this?
>
>
>
> --
> View this message in context: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__maven.40175.n5.nabble.com_mvn-2Ddeploy-2Dwithout-2Drebuilding-
> 2Dtp5866812.html&d=CwICAg&c=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
> BCjCmEiTk&m=Xz_0L6GMpakwuIrvdS8rmwwVvG4ICSqiZEtDVJHMOs4&s=ZcThl
> 4rMzxKkMuZmrS5XqZjAKrgLV_EAYpkF0jKPy7g&e=
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: mvn deploy without rebuilding?
Posted by Jörg Schaible <jo...@gmx.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: mvn deploy without rebuilding?
Posted by thully <tm...@eng.ucsd.edu>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org