On 1/17/2013 8:10 AM, Peter Klügl wrote: > On 14.01.2013 14:51, Richard Eckart de Castilho wrote: >> Am 14.01.2013 um 11:13 schrieb Peter Klügl <[email protected]>: >>> On 09.01.2013 18:41, Richard Eckart de Castilho wrote: >>>> Am 09.01.2013 um 14:35 schrieb Marshall Schor <[email protected]>: >>>> >>>>> You can add the server properties to your settings.xml, but please use the >>>>> encryption technique. >>>>> This would enable you to upload snapshots to the repository.apache.org >>>>> server, >>>>> for instance. >>>> Jenkins is configured to deploy snapshot versions of TextMarker to the >>>> Apache >>>> repository server after every build. There is no need to do that manually. >>>> >>>> The server credentials in the settings.xml would only be necessary for >>>> regular >>>> releases. >>> In case of a TextMarker release, I still have to do it manually, e.g., >>> because of the RC tag, right? >>> >>> I added the server information to my settings.xml (with encrypted >>> passwords). What about "<id>stagingSite</id>" (must match hard-coded >>> repository identifier in site:stage-deploy)? Do I need that element? Is that >>> important for the documentation? I thought the documentation will be >>> manually added to the website. I even do not know yet where it should be put >>> or linked. >>> >>> What are my next steps? Just following the steps mentioned in >>> http://uima.apache.org/release.html ? >> I didn't use the Apache Nexus yet, but the procedure appears to be pretty >> much the same as for the Sonatype OSS Nexus [1] which I have used in several >> projects. The link has some screenshots of Nexus you might find supplemental >> to the UIMA release documentation. >> >> If I understand the documentation right, you don't have to add any specific >> "staging" stuff anywhere. Just add the Nexus credentials to your >> settings.xml. Make sure the <id> of these credentials is the same used in the >> POM declaring the distributionManagement (I think that is the Apache master >> pom). >> >> When you run a regular "mvn -DautoVersionSubmodules release:prepare >> release:perform", the artifacts go to Nexus who puts it automatically into a >> "staging repository". I never had to use "stage-deploy". From that point, >> there are normally two options: >> >> - closing and promoting the repository so the artifacts get deployed to Maven >> Central. >> >> - closing and dropping the repository if something went wrong or if you >> discard a release candidate. >> >> People can test the RC by via the staging repository. >> >> If your release fails at some SVN operation like creating the tag, try >> providing "-Dusername=XXX -Dpassword=YYY" on the command line with your SVN >> credentials. > > Thanks for the information. > > However, is it really not neccessary to put something on my people.apache.org > webspace?
Here's how to think about this. A release can include parts that are intended to be accessed (after releasing) from Maven Central, or it can include parts that are intended to be accessed via the Apache distribution point (or its many mirrors). A recent discussion on the Infrastructure list says that if a part is intended to be accessed via Maven Central, it **also** **must** be put onto the Apache Mirror System. While this seems silly to me, it does allow one spot for people to find all released distributed artifacts from Apache. You can see this recent update to the dist point for maven projects, here: http://www.apache.org/dist/maven/ Your eventual release should consist of several things: 1) a source-release.zip with all the sources This goes on the Apache Mirror system. It is the main thing released by the ASF. 2) A convenience packaging of the build of the source, put into the Apache Mirror system, updating our Eclipse-update-site with a new subsite. 3) A release of the plugin/feature Jars and their signings that go into Maven Central. These are for use by people (including our team) who are doing builds of things (we use these to build the Eclipse-update-site, for instance). ------ To do the Vote, it's necessary to produce the signed artifacts and put them somewhere for people to test. For 1) - this should go into your people.a.o/~[userid]/public_html/XXXXX spot, where XXXXX is something like "TextMarker-2.0.0-rc1" or some other self-describing string :-). For 2) - this should go into your people.a.o.... also For 3) - these go into the repository.a.o "staging" spot. They do not go on people.a.o... > What about the update site? I wonder if the update site is build with released > artifacts, how can someone vote on a release candidate with no update site? Right, you have to provide (see above) an update site on your people.a.o.... so it can be tested/voted on. Since you'll be adding a new sub-site, your update will include changes to the composite and the new subsite itself. > > I assume it's enough to "mvn -DautoVersionSubmodules release:prepare > release:perform" and provide a SNAPSHOT update site at > http://people.apache.org/~pkluegl ? Almost. The results of release:prepare release:perform will be to produce non-snapshot versions of things in the /target/checkout (I think that's the name), and to deploy these to the "Staging" (not Snapshot) repo in repository.apache.org. You'll need to assemble the new eclipse update site into people.a.o... by copying the changed files from the uima-eclipse-composite-update-site's /target/checkout and your own Textmarker's eclipse-update-site. (This is because we haven't (yet) built any automation for this final assembly of the composite update site and its subsites.) > > Am I missing something? > > Do I have to adapt something because of the latest changes in INFRA-5746? Not yet. The latest changes in there come into play when the vote passes. Then, you have to do svn operations to alter the content in /release/uima to update it with the approved artifacts. -Marshall (hoping he didn't forget something ...) > Peter > > > > > > > >> Cheers, >> >> -- Richard >> >> [1] >> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide >> > >
