Re: mvn deploy without rebuilding?
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: [EXTERNAL] mvn deploy without rebuilding?
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:tmh...@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=CwICAg=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk=Xz_0L6GMpakwuIrvdS8rmwwVvG4ICSqiZEtDVJHMOs4=ZcThl > 4rMzxKkMuZmrS5XqZjAKrgLV_EAYpkF0jKPy7g= > 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
AW: JUnit tests for Maven plugin and Java annotations
Hello everyone,
found a solution by using the MojoRule class in my test:
@Rule
public MojoRule mojoRule = new MojoRule(this);
My test is still a sub-class of AbstractMojoTestCase.
The execution of my plugin within the test works like this:
this.mojoRule.executeMojo(basedir, "plugin-name");
"basedir" is of type java.io.File and points to the folder in which the example
pom.xml resides.
"plugin-name" is the name of the plugin without the "-maven-plugin" suffix.
Maybe this will help some others of you who face the same problem.
I don't know if there is a more straight-forward method like this...
Regards,
Gerrit
-Ursprüngliche Nachricht-
Von: Hohl, Gerrit [mailto:g.h...@aurenz.de]
Gesendet: Dienstag, 3. Mai 2016 11:48
An: users@maven.apache.org
Betreff: JUnit tests for Maven plugin and Java annotations
Hello everyone,
I'm currently writing a Maven plugin and I want to have some JUnit tests
for it.
The artifact maven-plugin-testing-harness offers an environment through
its AbstractMojoTestCase class.
After reading half of the Internet I also got it working.
But now I'm stuck as it seems to ignore the annotation of my plugin.
I used the Java annotations provided by the artifact
maven-plugin-annotations.
In the META-INF/maven/plugin.xml I see all the parameters.
But when I execute my JUnit test case - which is sub-class of the
AbstractMojoTestCase - I get null for all of these properties.
One example for these properties of my plugin:
@Parameter(defaultValue="${project}", readonly=true)
private MavenProject project;
Does AbstractMojoTestCase not supported Java annotations and also not
read it from the plugin.xml?
At least from the plugin.xml it should be able to read it, I think,
because it throws an exception if that file doesn't exist.
Or do I have to take some extra steps (e.g. method calls of
AbstractMojoTestCase) to get them set?
Regards
Gerrit
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
JUnit tests for Maven plugin and Java annotations
Hello everyone,
I'm currently writing a Maven plugin and I want to have some JUnit tests
for it.
The artifact maven-plugin-testing-harness offers an environment through
its AbstractMojoTestCase class.
After reading half of the Internet I also got it working.
But now I'm stuck as it seems to ignore the annotation of my plugin.
I used the Java annotations provided by the artifact
maven-plugin-annotations.
In the META-INF/maven/plugin.xml I see all the parameters.
But when I execute my JUnit test case - which is sub-class of the
AbstractMojoTestCase - I get null for all of these properties.
One example for these properties of my plugin:
@Parameter(defaultValue="${project}", readonly=true)
private MavenProject project;
Does AbstractMojoTestCase not supported Java annotations and also not
read it from the plugin.xml?
At least from the plugin.xml it should be able to read it, I think,
because it throws an exception if that file doesn't exist.
Or do I have to take some extra steps (e.g. method calls of
AbstractMojoTestCase) to get them set?
Regards
Gerrit
