Maven release:prepare-with-pom non-interactive - maven

I'm trying to release a project with Maven.
My project POM is containing -SNAPSHOT dependencies, so in order to perform the release automatically, I want to use the following maven command, based on the "maven-release-plugin" goals: mvn release:prepare-with-pom in order to prepare the project's pom.xml for releasing and resolve dependencies -SNAPSHOT versions automatically without edit them by hand.
Unfortunately I found this is working only in interactive mode from command line. The idea is that I'm wondering if this can be done without any manual interaction. I am using Bamboo as CI Server and I want to have this into a plan and perform this project releasing automatically. The --non-interactive or -B argument isn't working, actually if I'm using -B or --non-interactive argument the maven goal is failing.
This is the output for mvn release:prepare-with-pom:
H:\APPS\dev\cmtest\test-dependency\trunk>mvn release:prepare-with-pom -DdryRun=t
rue
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building test-dependency 0.0.4-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-release-plugin:2.0:prepare-with-pom (default-cli) # test-depend
ency ---
[INFO] Resuming release from phase 'check-dependency-snapshots'
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve th
em now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Depe
ndencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 1
Resolve Project Dependency Snapshots.: '${artifactGroup}:${artifactId}' set to releas
e? (yes/no) yes: : yes
What is the next development version? (0.1.3-SNAPSHOT) 0.1.3-SNAPSHOT: :
'${artifactGroup}:${artifactId1}_1' set to release? (yes/no) yes: : yes
What is the next development version? (0.0.2-SNAPSHOT) 0.0.2-SNAPSHOT: :
'${artifactGroup}:parent-pom' set to release? (yes/no) yes: : yes
What is the next development version? (0.0.3-SNAPSHOT) 0.0.3-SNAPSHOT: :
What is the release version for "test-dependency"? (${artifactGroup}:${artifactId1}_2) 0.0.4: :
What is SCM release tag or label for "test-dependency"? (${artifactGroup}:${artifactId1}_2) test-dependency-0.0.4: :
What is the new development version for "test-dependency"? (${artifactGroup}:${artifactId1}_2) 0.0.5-SNAPSHOT: :
[INFO] Transforming '${artifactId1}_2'...
[INFO] Updating ${artifactId1}_1 to 0.0.1
[INFO] Updating ${artifactId1} to 0.1.2
[INFO] Generating release POMs...
[INFO] Generating release POM for 'test-dependency'...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
So, can you help me please to find a trick in order to perform this maven command in non-interactive mode?
Thanks a lot

While your pom refers to snapshot releases I don't believe non-interactive is possible (maybe a fancy 'expect' script but that might be a bit much).
Releasing a library that relies on snapshots is very dangerous because the libraries can change from under your feet. Anyone using your library is going to assume that every time they use it they're getting the same jars, with the same SHAs, but in reality that's not the case. That's why maven makes it nearly impossible do to this.
I'd recommend concentrating on moving your dependencies to released versions, or if that's not an option, keeping your library as a snapshot. Keeping your library as a snapshot means that your clients are at least aware that the libraries they're using can change without their knowledge.

Related

Tycho build fails on Jenkins only for SCM Trigger

I have a little bit of strange Problem with Jenkins, Maven and Tycho and it is hard to find out who is the culprit.
All SCM Triggered Builds fail but all manually triggered builds succeed.
Jenkins Version : Jenkins ver. 1.527
Maven Version : 3.05
I have a modularized tycho build:
<modules>
<module>../main.plugin.test</module>
<module>../main.plugin.internationalization.at</module>
<module>../crud.plugin</module>
<module>../rest.plugin</module>
<module>../main.plugin</module>
<module>../main.feature</module>
<module>../product</module>
<module>../target-definition</module>
<module>../rest.plugin.test</module>
</modules>
Jenkins is configured as a simple maven build with modules.
It just executes:
-X clean deploy
When an SCM-Build is triggered some modules are not build.
When I build it manually everything is fine:
This behaviour is consistent. I already tried
switching to a different Maven version (3.05 / 3.04)
deleting the whole workspace prior to building
clean checkout of all sources
running of -X deploy (without clean)
Any amount of manual invocations succeeds. And any amount of scm triggers fails.
Both Maven logs look exactly the same until (working):
[INFO] Reactor Build Order:
[INFO]
[INFO] client-master
[INFO] crud-plugin
[INFO] main-plugin
[INFO] ------------.main.plugin.test
[INFO] ------------.main.plugin.internationalization.at
[INFO] rest-plugin
[INFO] main-plugin
[INFO] ------------.product
[INFO] target-definition
[INFO] ------------.rest.plugin.test
and (failing):
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] main-plugin
[INFO] ------------.plugin.test
[INFO] ------------.main.plugin.internationalization.at
[INFO] rest-plugin
[INFO] main-plugin
[INFO] ------------.product
[INFO] ------------.rest.plugin.test
The final error message therefore is:
Caused by: java.lang.IllegalStateException: ------------..client:------------..crud.plugin:eclipse-plugin:1.0.0-SNAPSHOT does not provide an artifact with classifier 'null'
Customer specific module names are replaced with ------------. in this question.
I have heard repeatedly of vague problems with Tycho builds on Jenkins. The reason for these problems seems to be that some Jenkins plugin triggering these builds hooks into the Maven lifecycle and this somehow collides with what Tycho does in the Maven internals.
For the problem that you are describing, it seems that the Jenkins plugin that you are using is changing the module build order. This may be okay for a normal Maven build (where all dependencies are declared in the POMs), but may fail for a Maven/Tycho build, where dependencies are computed by Tycho during the build.
To avoid this problem, you should trigger the Maven build in a way that is closer to a normal command line build. I found that the Invoke top-level Maven targets build step from the Maven Integration plugin works without problems.

Different behavior when running the Maven versions:use-latest-versions goal

The command I'm running is:
mvn -U -e versions:use-latest-versions -Dincludes=com.test.engines:engines -DgenerateBackupPoms=false -DallowMajorUpdates=false -DallowMinorUpdates=false -DallowSnapshots=false
I have, in my pom, a version such as 1.2.3-5-SNAPSHOT and I want to update it to the latest released version. This could be, for example, 1.2.3-7, or 1.2.3-5-SNAPSHOT may not have been released yet meaning the latest version is 1.2.3-4.
When running a maven command on my local Windows machine the versions plugin is working as I require it, however when running it on a remote Linux box (where I really need it to) it doesn't.
My local box shows:
When running a maven command on my local Windows machine the versions plugin is working as I require it, however when running it on a remote Linux box (where I really need it to) it doesn't.
[INFO] [versions:use-latest-versions {execution: default-cli}]
[INFO] Incremental version changes allowed
[INFO] Incremental version changes allowed
[INFO] artifact com.test.engines:engines: checking for updates from central
Props: {project.version=12.4.0-10-SNAPSHOT, project.parent.version=1.0.0, project.parent.groupId=com.test.pom, project.artifactId=edge-web, project.groupId=com.test.edge-web, project.parent.artifactId=pom}
[INFO] Updated com.test.engines:engines:jar:12.4.0-41-SNAPSHOT to version 12.4.0-40
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
Whereas the remote box shows:
[INFO] --- versions-maven-plugin:2.0:use-latest-versions (default-cli) # edge-web ---
[INFO] Incremental version changes allowed
[INFO] Incremental version changes allowed
[INFO] artifact com.test.engines:engines: checking for updates from nexus
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
When running:
mvn -Dplugin=versions help:describe
The output on both boxes shows the same version number:
Name: Versions Maven Plugin
Description: Versions Plugin for Maven 2. The Versions Plugin updates the
versions of components in the POM.
Group Id: org.codehaus.mojo
Artifact Id: versions-maven-plugin
Version: 2.0
Goal Prefix: versions
Does anyone know how I can get the same behavior as I do on my local machine? Or have any suggestions as to how I can investigate further?
I was using different versions of Maven. It seems even though the plugin version was the same I guess the method to resolve later versions in the core of maven must be different.
For reference the Mavan version can be checked using:
mvn --version
I also had to do similar to what is described here to allow me to run both Maven 2 and 3 from a single script.

maven deploy-file failed with 503: cannot find maven-metadata.xml

I am using Maven to integrate our project with others, maybe in a unpopular way and encountered issue.
We have a project that used to compile with Ant. Ant script is big and awesome, so when we are using Maven for integration, it is decided to keep compiling with Ant.
Now let's say Ant compile output is res-1.0-SNAPSHOT.tar.gz. (any filename can be possible but it IS tar.gz) And I am deploying the file to a nexus-hosted snapshot repository called "snapshots".
I tried to deploy with this command:
mvn deploy:deploy-file \
-DgroupId="com.my-company" \
-DartifactId="res" \
-Dversion="1.0-SNAPSHOT" \
-Dpackaging="tar.gz" \
-Dfile="res-1.0-SNAPSHOT.tar.gz" \
-Durl="http://our-nexus-ip/nexus/content/repositories/snapshots" \
-DrepositoryId="snapshots"
I have a simple settings.xml in ~/.m2 with proxy and server settings. However server settings is not being used in current progress yet, wrong passwords don't get errors.
The output is like this:
[[root#cnbi maven]# ./run.sh
+ mvn deploy:deploy-file -DgroupId=com.my-company -DartifactId=res -Dversion=1.0-SNAPSHOT -Dpackaging=tar.gz -Dfile=res-1.0-SNAPSHOT.tar.gz -Durl=http://135.252.234.142:8081/nexus/content/repositories/snapshots -DrepositoryId=snapshots
Warning: JAVA_HOME environment variable is not set.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [deploy:deploy-file] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [deploy:deploy-file]
[INFO] Retrieving previous build number from snapshots
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error retrieving previous build number for artifact 'com.my-company:res:tar.gz': repository metadata for: 'snapshot com.my-company:res:1.0-SNAPSHOT' could not be retrieved from repository: snapshots due to an error: Error transferring file
Server returned HTTP response code: 503 for URL: http://135.252.234.142:8081/nexus/content/repositories/snapshots/com/my-company/res/1.0-SNAPSHOT/maven-metadata.xml
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 51 seconds
[INFO] Finished at: Tue Jun 12 08:44:13 CST 2012
[INFO] Final Memory: 7M/209M
[INFO] ------------------------------------------------------------------------
You see, it fails to find maven-metadata.xml. It is for certain, the file and its folder "com/my-company" do not exist at all in the repository.
Besides any misuse of Maven you may find, my questions are:
1) am I using Maven in the right way? (deploying tar.gz, using deploy:deploy-file...)
2) are there incorrect parameters?
3) what is maven-metadata.xml for? It is not there but Maven insists to find it -- I guess it is generated, am I missing some steps?
The solution might be stupid, I am really not familiar with Maven. Unfortunately it has to be done... Please, help me out of this.
Maven version is 2.0.11. Let me know if you want to know more.
I had the same problem and there was a bug in our nexus.
Using maven3 (with same settings.xml, pom.xml and .m2 repo) solved our problem and its easier than upgrading nexus.
You can check this bug also.
If you're still stuck with using Ant, I would recommend you at least consider adding Ivy to the picture, as your dependency manager. If I recall correctly, it was able to update maven-metadata.xml files in the repository.
Have a look at this example.

What is Maven dependency:purge-local-repository supposed to do?

I'm trying to purge the local repository of a project dependency before launching releasing it in order to make sure every dependency required is on the central repository and is downloaded from it.
In the project folder (containing the pom.xml), I launch the following command:
mvn clean dependency:purge-local-repository -DreResolve=false -Dverbose=true
The project's POM is very simple and just have a declared dependency to junit:junit:3.8.1
The command's output give me:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building corelib-api 0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) # corelib-api ---
[INFO] Deleting d:\Users\fpaillard\git-repositories\TEST_CORELIB\corelib-api\target
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building corelib-api 0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:purge-local-repository (default-cli) # corelib-api ---
[WARNING] Missing POM for junit:junit:jar:3.8.1
[INFO] Skipping: corelib-api. It cannot be resolved.
[INFO] Nothing to do for project: test:corelib-api:jar:0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.953s
[INFO] Finished at: Mon May 14 11:34:40 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO] ------------------------------------------------------------------------
When I look in the local repository (path checked with mvn help:effetive-settings), junit JARs nor POMs are still in .m2/repository/junit/junit/3.8.1 folder.
Isn't dependency:purge-local-repository supposed to delete it?
I don't understand the WARNING of the output above. Why is junit:junit:jar:3.8.1 POM missing? It is still present at .m2/repository/junit/junit/3.8.1/junit-3.8.1.pom
Is the problem related to the INFO line Skipping: corelib-api. It cannot be resolved.? corelib-api is the artifact name of the project I ran mvn dependency:purge-local-repository against.
I know this is old, but I had the same issue, and adding -DactTransitively=false to the command line fixed this issue. I'm unable to tell why it helped, but it did...
I hope this helps.
Looking at the documentation, disabling the actTransitively option causes the purge goal to only purge the dependencies that are named directly by your pom.xml. When it is time for the build, Maven automatically pulls not only your direct dependencies, but all of the TRANSITIVE dependencies down into your local repo as well.
When the purge goal is looking for what to delete, if it finds other dependencies in the dependencies' poms, it transverses those dependencies to figure out the entire tree in your local repository that can be purged. To do this, it at least needs the transitive project's pom.xml. If it cannot find it in the local repo, or if it thinks there might be a more recent version to analyze, it will go to the external repositories to find it.
I don't think it actually tries to download full project content before it starts purging. But since it at least pulls down the projects' pom.xml files, it will complain if it can't find one just like it would if it were resolving dependencies for an actual build.
Besides just preventing Maven from accessing external repositories while purging, another practical reason would be if you have two projects that have the same transitive dependency, and you don't want the purge from one to affect the performance of the other (since the latter will have to download any missing dependencies again).
On the other hand, something to carefully consider is that if you do NOT allow the purge to consider all of the transitive dependencies possible, you stand to leave a set of downstream dependencies sitting in your local repository that you would otherwise have wanted to remove.
I could make a case for saying that the output you are getting is either unnecessary or preventable with another flag like "reportInaccessibleDependencies=false". But unless it is killing your build, I wouldn't say it is anything to worry about.

Transitively download a Maven artifact to the local repository

I am trying to download a specific artifact (and all of its dependencies) to a machine's local repository.
It would seem that using the dependency:get goal would be the best option for this, but despite the documentation it does not seem to actually get the transitive dependencies.
Here is an example where I have tried to use dependency:get to download the spring-core jar and all of its many dependencies. You'll notice that the spring-core jar is the only thing downloaded despite the fact that this was done after cleaning the local repository.
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.2:get -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:3.0.5.RELEASE -Dtransitive=true
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.2:get (default-cli) # standalone-pom ---
Downloading: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar
Downloaded: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar (374 KB at 548.4 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.401s
[INFO] Finished at: Wed May 25 00:29:47 CDT 2011
[INFO] Final Memory: 7M/107M
[INFO] ------------------------------------------------------------------------
My questions are:
Is this a bug with the dependency:get goal?
If not, what am I doing wrong?
Are there any alternatives methods I could use to accomplish my initially stated goal?
If this is a one time or irregular occurrence for you, The simplest thing to do would be to define the dependency in a POM and run mvn package or similar to retrieve the dependency artifacts. You could also try mvn dependency:sources if you'd like to have the source jars too.
If this is something you want to do more regularly or as part of a process, you could look at using Aether directly to retrieve the dependencies for you.
Another approach if this is something you need to do regularly to manage groups of artifacts into your internal development ecosystem is to use Nexus' procurement suite to retrieve the dependencies and manage them into your repository.
You might can go with this solution
1) Download the artifact as you described (I tested with version 2.5.2)
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true
2) Download the pom (-Dpackaging=pom) of this artifact
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true -Dpackaging=pom org.apache.maven.plugins:maven-dependency-plugin:2.2:get
3) Use the downloaded pom to copy all dependencies via the dependency:copy-dependency gaol
c:\test>mvn -DoutputDirectory=C:/test/dependency -f C:/<path-to-repository>/org/springframework/spring-core/2.5.2/spring-core-2.5.2.pom dependency:copy-dependencies
You will find the dependencies (including test and optional scope!) in the created c:\test\dependency folder. To exclude test and optional scope use -DincludeScope=runtime.
You need to dynamically build some path information (e.g. path to the pom in your repository) to set up this solution and also need to bring the artifact itself together with its dependencies but it should work in a script without generating a special pom (which might be easier).
It would appear the answer to question #1 (Is this a bug with the dependency:get goal?) is yes. As of 5/25/2011 issue MDEP-308 is still unresolved.

Resources