THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
In trunk/bin, there is a DoMerges.java program that assists in the merging. If the branch is setup with .gitmergeinfo, if you run it from the root directory of the checkout, it will prompt for every commit on master to see if you want to "Merge" it, "Block" it, or "Ignore" it. It displays the commit log first so you can see what was involved. You can also check the cxf-commits archive to see the full details of the commit to help decide what action to take. If you select "Merge", it will merge the change and then prompt before committing. That will allow you to look at the merge and resolve any conflicts. (or even revert it if you didn't mean to hit Merge)
...
| No Format |
|---|
mvn release:prepare -Peverything,jaxws22 mvn release:perform -Peverything,jaxws22 |
| Warning |
|---|
If you are performing the release on a Mac, it is advisable to add -DpushChanges=false to the "release:prepare" step above. The version of git that Apple ships with some versions of OSX has problems pushing the changes in quick succession from the release plugin and can become corrupt. Having the release plugin NOT push the changes and then running "git push -tags origin master" works around that problem. |
...
| Warning |
|---|
It is recommended to name the local maintenance branches the same as the remote ones ("2.7.x-fixes", "3.0.x-fixes", ...) to avoid issue with the branch names when running the release plugin. |
The above commands tag the release, update the poms versions, etc., then build it (off the tag), gpg sign and deploy everything (including source jars and javadoc jars) to the Nexus repository location. When the build is done staging, you next need to login to the Nexus repository and "close" the staging area (click on Staging Repositories in the left-side menu, select the repo you just uploaded and then select the close button.) Closing is very important. After the staging area is closed, note the URL for the staging area as you will need that for the vote.
...
- Update the download page - around 24 hours after committing the distributions, update the download page, release notes, etc. to point at the new versions. At that stage you'll want to delete (svn rm) the previous version of each branch you uploaded to https://dist.apache.org, so if you added https://dist.apache.org/repos/dist/release/cxf/2.6.3 and https://dist.apache.org/repos/dist/release/cxf/2.5.6, you'll want to remove https://dist.apache.org/repos/dist/release/cxf/2.6.2 and https://dist.apache.org/repos/dist/release/cxf/2.5.5. (Older versions will still be available at http://archive.apache.org/dist/cxf/ and are referenced from there on the CXF download page.)
Javadocs - the javadocs in the distribution are a limited set of javadocs useful for MOST people. However, the CXF website contains a more complete set of javadocs. To generate the docs for the site, from the source distribution (or git tag), run:
Code Block mvn javadoc:aggregate mvn package -DskipTests=true javadoc:aggregate-no-fork -pl distribution -am -Peverything -Dmaven.javadoc.skippedModules=cxf-testutilsThe first call (which WILL fail while trying to process some of the system tests) makes sure all the necessary things are built, code generated, etc... The second call will generate the javadoc for the site. Then copy the contents of target/site/apidocs to a new versioned directory in
Unpack the javadocs from the appropriate cxf-bundle-VERSION-javadocs.jar into the appropriate directory inan svn checkout of https://svn-master.apache.org/repos/infra/websites/production/cxf/content/javadoc and commit the new version. Make sure any new files are added.
- Unpack the schemas directory from the appropriate cxf-bundle-VERSION.jar and check if any of the schemas in https://svn-master.apache.org/repos/infra/websites/production/cxf/content/schemas need updating.
...