quote
http://blog.csdn.net/shirley_john_thomas/article/details/52598308
What is version management
First of all, version management here does not mean version control, but this article assumes that you have basic version control Knowledge of the basic usage of subversion. The version in version
management refers to the version of the artifact, not the version of the source code (such as rXXX common in subversion, or a commit number of sha1 for a commit in git).
For example, I have a project whose artifactId is myapp. As the project progresses, we will generate some jars like this: myapp-1.0-SNAPSHOT.jar, myapp-1.0.jar, myapp-1.1-SNAPSHOT.jar,
myapp-1.0. 1.jar and so on. You may say, this is very simple, I change the version in the POM, mvn clean install is not finished? But this is only the surface. In this article, I will describe the difference between snapshot and release version, how to
automate version release (if your project has dozens of modules, you will feel that it is very painful to manually change the POM to upgrade the version), combined with To automate the release process, maven-release-plugin will also be introduced here.
In addition , some scm concepts are also involved, such as tag and branch.
Prerequisite: Version Control
Anyway, we all need to build a project and submit it to SCM, here I use subversion as an example. You must have a configured subversion repository, here I created an empty svn repository whose address
is : https://192.168.1.100:8443/svn/myapp/ Now, there are only three empty typical ones in this directory Subdirectories: /trunk/, branches/, tags/. Used to store trunks, branches, and tags, respectively.
Then import the project into the svn repository, go to the project root directory, and run the following command:
[java] view plaincopy
svn import -m 'project initialization' https://192.168.1.100:8443/svn/myapp/trunk
(note that this Do you will import all the files in the directory into the svn library, but some of these directories and files should not be imported, such as the /target directory, and eclipse related project files)
Currently, we set the version of the project to 1.0-SNAPSHOT.
Why use SNAPSHOT?
Let me start by saying what it would be like without SNAPSHOT. Suppose your project has 2 modules, A, B, where A depends on B. These three modules are developed by two individuals, A and B, respectively. In the development process, because A is dependent on B
, every time B makes a change, it will affect A. Therefore, after B submits some changes, it needs to be seen by A. At this time, what should we do? B said to A, "You check out my code, build it and it will be OK", A is a little unsympathetic
Wish, but still did, check out the code, svn clean install, and then found that the build went wrong, and a test did not pass. A was depressed and said to B, "Your code doesn't work at all, I don't want to build it, you can build it for me",
B saw that his code could not be built, so he went back and solved it, and then made a jar package , throw it to A, A is right, the groupId, artifactId, put it in his own .m2/repository/ directory, OK, it can be used.
So B did this every time he updated, packaged, copied, and then A pasted and used... Gradually, everyone found that this was a very stupid method. It was purely manual labor, and the most BS thing for programmers was repetitive labor. One day, A said to B, "Do you
know nexus? You can just publish your jar on nexus, and I'll download it automatically when I want to use it. That's great!" B said, "Oh? There is such a good thing, I Go and see" So B discovered the new continent of nexus, and successfully released B to
nexus. (See, Getting Started with Nexus, (graphics)).
However, please note that everything we have here assumes that there is no SNAPSHOT, so if B does not change the version, after A downloads such as B-1.0.jar once, maven thinks that it already has the correct version of B, and will not download it again.
load. A found this problem and said to B, "I can't see your update, have you updated it?" B said "Impossible! Let me see", so he checked the C-1.0.jar downloaded by A and found that a few days ago. B patted his head and said, "It's easy, I'll just
update my version, I'll publish a B-1.1.jar, and you can update the dependency version."
There is a problem here. It is obviously not the correct management method to update a version at a time. In addition, B has to constantly notify A to update the version that depends on B. Are you tired? 1.0, or 1.1, 2.0, all represent stable
Sure, is it stable to change the version so casually?
So Maven has the concept of SNAPSHOT version, which corresponds to the release version, which refers to stable release versions such as 1.0, 1.1, and 2.0.
Now B can set the version of B to 1.0-SNAPSHOT, after each change, mvn deploy to nexus, each time deploy, maven will change SNAPSHOT to a timestamp of the current time, such as B-1.0-
SNAPSHOT.jar to After nexus, it will look like this: B-1.0-20081017-020325-13.jar. When Maven processes A's SNAPSHOT dependency on B, it will download the latest jar according to this timestamp. By default
, Maven updates once a day. If you want Maven to force an update, you can use the -U parameter, such as:
[java] view plaincopy
mvn clean install -U
Now things are simplified like this: B makes changes, then mvn deploy, A can get the latest B with the simplest maven command.
From 1.0-SNAPSHOT to 1.0 to 1.1-SNAPSHOT
SNAPSHOT means snapshot. After the project reaches a stage, it needs to release an official version (release version). A formal release requires the following work:
in the trunk, update the pom version from 1.0-SNAPSHOT to 1.0 ,
tag 1.0 with an svn tag
and perform mvn deploy against the tag, release the official version, and
update the trunk from 1.0 to 1.1-SNAPSHOT
You can do these things manually step by step, nothing more than some svn operations, some pom editing, and some mvn operations. But you should understand that doing these things manually is cumbersome and error-prone. So here I introduce the use of the maven plugin to automate this series of actions.
SCM
First, we need to add scm information to the POM, so that Maven can complete the svn operation for you. Here my configuration is as follows:
[java] view plaincopy
<scm>
<connection>scm:svn:http://192.168.1.100: 8443/svn/myapp/trunk/</connection>
<developerConnection>scm:svn:https://192.168.1.100:8443/svn/myapp/trunk/</developerConnection>
</scm>
It should be noted that many windows Using the tortoiseSVN client instead of the svn command line client will cause all svn related work in Maven to fail, so you first make sure that svn --version works.
Distribution repository
To let Maven help us automatically publish, first we need to configure the distribution repository. For this, see Maven Best Practices: Maven Repositories - Distributing Artifacts to Remote Repositories.
maven-release-plugin
Next, we need to configure maven-release-plugin, this plugin will help us upgrade the pom version, submit, tag, then upgrade the version, submit again, and so on. The basic configuration is as follows:
During execution, you will encounter this prompt:
What is the release version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.0: :
——"Do you want to 1.0-What version is SNAPSHOT released? The default is 1.0." All I want is 1.0, just press Enter.
What is SCM release tag or label for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) myapp-1.0: :
——"What is the name of the released tag? The default is myapp -1.0." I still want the default value, just press Enter.
What is the new development version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :
-- "What is the new version on trunk? Defaults to 1.1- SNAPSHOT." Ha, the release plugin will automatically update the version to 1.1-SNAPSHOT for me, very good, just press Enter.
Then the screen is swiped, maven is building our project, and some svn operations are performed, you can check the log carefully.
So what is the result? You can browse the svn repository:
we have an extra tag: https://192.168.1.100:8443/svn/myapp/tags/myapp-1.0/, which is the version 1.0 that needs to be released.
Look at the POM in the trunk, and its version is automatically upgraded to 1.1-SNAPSHOT.
Isn't that what we want? Wait, something seems to be missing, by the way, 1.0 hasn't been released to the repository yet.
Hold your breath again and execute:
[java] view plaincopy
mvn release:perform
maven-release-plugin will automatically check out the tag we just hit, then package and distribute it to the remote Maven repository. So far, the entire version upgrade, Tagging, publishing, etc. are all done. We can see the official release of version 1.0 in the remote Maven
repository.
This is an automated, official version release!
Maven's version
rules We mentioned the difference between SNAPSHOT and Release versions earlier. Now let's see why there are versions such as 1.0, 1.1, and 1.1.1, and what are the rules here.
Maven mainly defines version rules like this:
[java] view plaincopy
<major version>.<minor version>.<incremental version>
For example, 1.2.3, the major version is 1, the minor version is 2, and the incremental version is 3 .
The major version generally represents a major architectural change of the project. For example, Maven 1 and Maven 2 are already different in architecture, and Maven 3 and Maven 2 will also have great changes in the future. Minor versions generally represent some functional
additions or changes, but no architectural changes. For example, compared to Nexus 1.2, Nexus 1.3 adds a series of new or improved features (repository mirroring support, improved repository management interface) etc.), but from a large architectural
For example, 1.3 and 1.2 are no different. As for the incremental version, it is generally some small bug fixes, and there will be no major functional changes.
Generally speaking, after we release an important version, we will develop a new version. For example, after myapp-1.1 is released, we will start to develop myapp-1.2. As myapp-1.2 has new major feature additions and changes,
it will become unstable before release for testing, while myapp-1.1 is a relatively stable version, now the problem is, we found in myapp-1.1 Some bugs (of course there are also in 1.2), in order to be able to fix bugs and still release a stable version within a period of time
, we will use branches, we will open a branch 1.1.1 based on 1.1, in this branch Fix bugs and release quickly. This not only ensures the stability of the version, but also enables bugs to be
quickly fixed, and does not stop the development of 1.2. It's just that every time a bug in branch 1.1.1 is fixed, the code needs to be merged into 1.2 (trunk).
The above is why we use incremental versions.
The actual combat branch
The current version of our trunk is 1.1-SNAPSHOT. In fact, according to the version rules explained earlier, it should be 1.1.0-SNAPSHOT.
Now we want to release 1.1.0, then upgrade the trunk to 1.2.0-SNAPSHOT, and start a 1.1.x branch to fix bugs in 1.1.0.
First, before releasing 1.1.0, we create the 1.1.x branch and run the following command:
[java] view plaincopy
mvn release:branch -DbranchName=1.1.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
This is the branch goal of maven-release-plugin, we specify the branch name as 1.1.x, which means there will be versions 1.1.1, 1.1. 2 and so on. updateBranchVersions=true means update the version in the branch, while
updateWorkingCopyVersions=false means not changing the version in the current working directory (here trunk).
After running the command, we will get a prompt like:
What is the branch version for "Unnamed - org.myorg:myapp:jar:1.1-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :
—— "What is the version number in the branch? The default is 1.1-SNAPSHOT" At this time, the version we want is 1.1.1-SNAPSHOT, so enter 1.1.1-SNAPSHOT, press Enter, and maven continues to execute until the end.
Next, when we browse the svn repository, we will see this directory: https://192.168.1.100:8443/svn/myapp/branches/1.1.x/, open the POM file in it, and its version is already 1.1.1-SNAPSHOT .
Once the branch is created, you can use release:prepare and release:perform to tag 1.1.0, upgrade trunk to 1.2.0-SNAPSHOT, and distribute 1.1.0.
So far, everything is OK.
summary
This article describes how to use Maven with svn for version management. Explains the origin of SNAPSHOT versions in Maven, and the rules for Maven to manage versions. Combined with SCM's tag and branch concepts, it shows how to use
maven-release-plugin to release versions and create branches. This article involves a lot of content and is slightly complicated, but mastering the skills of version management is very important for the regular management of the project. Maven provides us with
some mature mechanisms that are worth mastering.