When you are done the project should be tagged, thing that you can confirm navigating to the tagBase url.ġ0. So be sure you update your own jar dependencies if any forcing the project to use a release version. Pay attention to dependencies, maven will complain if you try to use snapshots but if you decide so it will allow you to point to them.
Of course when there is a business decision to change the minor or major version numbers then you simply edit the pom.xml and commit the code to SVN before attempting to run release:prepare. Default options should be OK as they ensure the pom.xml gets updated to next version number. If already checked out be sure there are no differencesĩ. Also be sure to use the mirrors node to ensure you will download dependencies only from your local repository. Edit your ~/.m2/settings.xml file making sure the credentials for your artifactory reposiitory are correct. Add the scm connection property to the pom.xmlĦ. This way the build will be using 'UTF-8' encoding to copy filtered resources.ĥ. Just in case you use Windows or Mac from the machine you will be releasing do yourself a favor and add the below to you pom.xml. Modify the project pom.xml to specify where to upload the result of the build (final released product). Modify the project pom.xml to specify where to tag the code (svn tags folder).ģ. It must end with the string “-SNAPSHOT”.Ģ.
Modify the project pom.xml to specify the version number. I have released from my local machine from time to time but I have found way safer to do it always from the same server where other developers can login and follow exactly the same steps. IMO it is *not* good to release from your local machine if you are part of a team.
You need subversion and maven2 (version 2.2.1 or above) packages installed ( For the release server I use linux as OS ) I have been using Maven and Subversion for this task with very good results. Releasing and deploying a Java Web application (WAR application) involves several steps.
0 kommentar(er)
