Version for Maven branch update projects automating the release workflow

I have a difficult question for solving issues related to Maven version control of automated projects, I hope that I will find a suitable solution based on your experience and advice.

The problem is this: We have a huge mavenized java product, which consists of ~ 200 very interdependent various projects. We agreed that each project should be developed independently, so that each of them has its own life cycle. All this works fine at the development stage, no problem. The problem arises when we prepare the release for these projects: because there are so many projects, manual changes are a pain, so we decided to find an automated solution to solve the release process.

The preferences are as follows: We all agreed that the release policy from the point of view of SVN should be as follows: - all development should be performed on the SVN trunk, releases should be created and maintained on branches. Each completed release should automatically create a tag.

The policy from the point of view of MAVEN is as follows: - before the release of the project, we first copy the backbone to the branch in order to have control over the support of projects using a branched code. We select a version control system: Major.Minor.BuildNumber-SNAPSHOT (e.g. 1.0.0-SNAPSHOT) . When branching the code, we want to change the project version number by increasing MinorVersion (for example, trunk-1.0.0-SNAPSHOT will become 1.1.0-SNAPSHOT and 1.0.0-SNAPSHOT will be copied and released in the newly created branch) - when we decide that the project mature enough to be released, we release it using the maven-release plugin ( mvn release: clean version: prepare release: execute ) so that our version of the project will be converted from Major.Minor.BuildVersion-SNAPSHOT (e.g. 1.0.0 -SNAPSHOT) in Major.Minor.BuildVersion (for example, 1.0.0) , then it will be prepared for the next iteration of development, for example: Major.Minor.BuildVersion + 1 -SNAPSHOT (e.g. 1.0.1-SNAPSHOT)

The problems we face are related to project versioning. Thus, during the development phase on the trunk, all projects use the latest SNAPSHOT versions of their dependencies ( mvn versions: use-latest-versions -DallowSnapshots = true -DupdateDependencies = true ), but when we think it's time to start the release procedure and get ready to code separation, there are problems: we start branching

  • parent-pom

    ( mvn -B release: clean release: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel. $ {group_id}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT )

    • copy the project from the trunk to the newly created branch, convert the pom version to the trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT
  • project-independent projects

    ( mvn -B release: clean release: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel. $ {group_id}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT versions: update-parent -DallowSnapshots = true )

    • copy the project from the trunk to the newly created branch,
    • converts the punk version of version 1.0.0-SNAPSHOT, becoming 1.0.1-SNAPSHOT
    • update parent-pom.version: 1.0.0-SNAPSHOT will become 1.1.0-SNAPSHOT
  • dependent projects:

    ( mvn -B release: clean release: branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel. $ {group_id}: $ {ProjectID} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT versions: update-parent -DallowSnapshots = true versions: use-latest-versions -DallowSnapshots = true -DupdateDependencies = true )

    • copy the project from the trunk to the newly created branch
    • convert pom version to trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT
    • update parent pom on trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT
    • update already forked dependency projects from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT

The first problem is that there is as yet no argument for increasing MinorVersion when branching a project, maven-release-plugin 2.2.2 does not increase MinorVersion increment on the trunk when branching, so we need to use -Dproject.rel. $ {groupId}: $ {projectId} = 1.0.0-SNAPSHOT -Dproject.dev. $ {GroupId}: $ {projectId} = 1.1.0-SNAPSHOT and change them manually for each project, so 200 times every time we prepare a new version.

I am wondering if this is not a way to do the whole procedure described in some way in an automatic way and you do not need to constantly perform all these changes manually. We even consider the modularity of this product in order to possibly split this 200 projects into 100, but this is unacceptable, since the idea is to have proper version control of the projects and have all projects with their own life cycle, therefore the aggregator (I mean classic) is not discussed here.

We use SVN as VCS, Maven as a build tool (you may have already figured this out :)), and Bamboo as a CI server (in fact, instead of the Maven Dependency Processor function, Bamboo does not help me with regard to the version issue).

Do you have ideas to find the right solution to this problem, maybe another plugin that will help (versions-maven-plugin don't change versions automatically on branch), maybe a different point of view for this, I don't know ..., any help or sugestion are welcome.

Thanks!

+7
source share
1 answer

I try to avoid saving versions of internal projects in the <properties> section of the parent pump, since every time I issue a project, the variable <version>${project.version}</version> will switch with the explicit version of the project, for example:

 <properties> <project_A.version>1.0.0-SNAPSHOT</projectA.version> </properties> 

stored in the parent pom, translated into pom projects like: $ {project.version} , will become 1.0.1-SNAPSHOT when this project is released and will overwrite the version of <project_A.version> from parent-pom <properties> . So this trick of keeping project versions as properties in a centralized place like parent-pom is valid until you release the projects. This is a strictly related question.



Now, if you want, I can tell you more about project releases using this <properties> substitution: Suppose you want to release project_A , what will you do with <projectA.version> stored in the parent pom <properties> , which is version of -SNAPSHOT, when will you start releasing your parent pom? I mean, to release a project, you first release all its dependencies and the associated parent pom? otherwise, your project release will fail because it points to the -SNAPSHOT version of the parent. Now you release the parent pump by storing the <-SNAPSHOT version of project_A <properties> , then when you release project_A , your project will refer to the newly created version of the parent pom, the version of the parent pom that references the -SNAPSHOT version of your project_A , still not a problem, since your parent pom keeps the true version of your project_A until your released version of projectA (say 1.0.0) references the same released version of the parent pom that contains version 1.0.0-SNAPSHOT of your project_A , and now you have a problem because your parent pom <properties> storing incorrect information. Of course, you can hack the parent pom when it is released and save the version of project_A , but this is against the rules, and I would not agree with it at all, plus other scenarios when this “hack” will cause more problems than help.

I apologize if this sounds rather complicated and detailed, but I just want to explain as much as possible the real situation of life, not only theoretically, but also that I also need to keep in mind that I have 200 more projects that I need as- then level off.

0
source

All Articles