RE: [EXTERNAL] mvn deploy without rebuilding?

[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