maven-release-plugin

Given the following sample multi-module project: aggr/pom.xml (Version 1.0-SNAPSHOT) aggr/parent/pom.xml (Version 2.0-SNAPSHOT) aggr/app/pom.xml (Version 3.0-SNAPSHOT) aggr/comp1/pom.xml (Version 4.0-SNAPSHOT) where parent is the parent of any other pom and app has a dependency of comp1. Releasing via release:prepare/perform just works fine as long as the aggr folder has the same structure within the svn repository (repository/trunk/aggr/parent.pom, ...). Now when I want to use the same project but with svn:externals, the release-plugin doesn't work stating that comp1: Can't release project

I am working on Automated Build using maven and Jenkins. I am looking for best open source Repository Management for Maven. So that I can have an integaration between Maven and jenkins via respository manager. You have at least three choices that I know of Nexus Artifactory Apache Archiva I have used all the three and each has pros and cons. I would go with Nexus since it is backed by Sonatype who are also involved in maven development. I liked the Artifactory User Interface though Both Nexus and Artifactory have supported professional editions as well. These are linked from the maven site as

Lets say we have 3 layers project. DB, Business, Web and aggregating pom. Project |-DB | |-pom.xml |-Business | |-pom.xml |-pom.xml All modules are ment to be released and branched together, so Aggregator pom is configured to assign the same version to all submodules. We have the following versions: DB-0.1-SNAPSHOT Business-0.1-SNAPSHOT which depends on DB-0.1-SNAPSHOT Web-0.1-SNAPSHOT which depends on Business-0.1-SNAPSHOT When doing release:prepare , all versions updated to 0.1, but prepare fails because there is no DB-0.1 in dependency yet. One solution is to create different projects for

Recently having switched source code repository for a project to GitHub from SourceForge I need to update the maven release process to match. I followed this link for configuring the "scm" section of the pom. The GitHub repository is shown here . Everything else is as it was when using SVN (for publishing to https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-4.MavenRepositories ). So then I invoke mvn clean release:clean release:prepare release:perform and the output is as follows [INFO] --- maven-release-plugin:2.1

I have configured a Jenkins job to release my maven project automatically. This is done by using the following: mvn --batch-mode clean release:prepare release:perform In batch mode the release version and the development version will be determined automatically. This is exactly what I want. The problem is that I want to increase the 2nd number of the version instead of the 3rd one. So when I release version 1.2.0, the next development version must be 1.3.0-SNAPSHOT. Not 1.2.1-SNAPSHOT. Adding a commandline parameter is not an option, because that forces me to constantly edit the build job. Any

In our SVN repo, we store tags like this: trunk project_a project_b branches project_a branch_x branch_y project_b tags project_a 1.0 1.1 project_b 1.0 When I run the Maven release plugin's " prepare " goal on project A, by default it creates the tag as "tags/project_a-x.x", which does not match my tag naming scheme above. I am thus depending upon whoever does the release (i.e. a fallible human) to spot this and change the tag to "tags/project_a/x.x". How can I tell the release plugin to use the correct format by default? The "prepare" goal has a " tag " configuration option that claims to do

The POM that my project inherits contains some <pluginManagement> for the release plugin that specifies some additional arguments . My question is: Is there a way to override the arguments parameter from the command line in this case? The parent POM has this: <pluginManagement> <plugin> <artifactId>maven-release-plugin</artifactId> <configuration> <arguments>-Prelease</arguments> </configuration> </plugin> </pluginManagement> Due to that the command line argument doesn't work: mvn release:prepare -Darguments="-Pmock -Prelease" The -Darguments="-Pmock -Prelease" part has no effect. When

To clarify the question : I am looking for established best-practices or a pro/con analysis of known practices by project lifecycle I mean : deploy to pre-integration, integration, QA, preprod and prod environment. For some context: Our project deploys to integration and QA every week, currenlty we create a new release for each integration deployment, but this doesn't feel right. It leads to updating all the poms every week breaking dev level dependencies, forcing every dev to do a refresh of their eclipse configurations. We have large workspaces and eclipse doesn't handle the refreshes so