xdocs/testing-builds.xml - uima-site - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>

 <!--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

   https://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
 -->
 <document>

 <properties>
 <title>Testing Release Candidates</title>
 <author email="dev@uima.apache.org">
  Apache UIMA Documentation Team</author>
 </properties>

 <body>

 <section name="Testing Release Candidates">
   <p>
     This page has information for testing release candidates.
   </p>
   <p>
       Prepare for testing by going to
     <a href="building-uima.html">building-uima</a>
     and doing the one-time setup, if you haven't done this already.  This includes installing Maven 3.
   </p>
 </section>

 <section name="Overview">
   <p>See <a target="_blank" rel="noopener" href="https://www.apache.org/dev/release.html#what-must-every-release-contain">"What must be included in a release".</a>
   To approve a release, it is good to do the following tests:
   <ul>
     <li>svn export the SVN tag for the code, and compare this to the unzip of the source-release.  These should be the same, except for some minor things;
     use your good judgement.</li>
     <li>Check building from source:  In your local .m2, delete the files being built (a good thing is to
     delete the "uima" directory), then get the source-release, unzip it, and run mvn install at the top level, to see if it builds.</li>
     <li>Check that the license and notice files are present in the source and binary distributions, and that the binary distributions have license/notice parts
     incorporated into the top-level license/notice files for any included artifacts being distributed.</li>
     <li>Check that the Jars have appropriate license / notice files for things contained within them.</li>
     <li>When an Eclipse update site is being released, try installing that into a fresh unzip of Eclipse 3.7.2 or later, and then verify the functionality seems present.
     When installing, it should show the standard licensing boilerplate, that refers (like the Eclipse user agreement) to embedded license/notice files.</li>
   </ul>
   </p>

 </section>
 <section name="Testing a source-release">

 <ol>
   <li>Download the ....source-release.zip file from the staging repository, for the
   top-most released artifact.  (Multimodule releases will have one top-level release artifact).
   </li>
   <li>Unzip.</li>
   <li>cd to the top level release artifact directory.</li>

   <li>Run
   <pre>mvn install</pre>
   to verify it builds from source.</li>

   <li>Inspect the unzipped source to verify license/notice files are in place.</li>
   <li>Run whatever further tests might be appropriate for the release.</li>
   </ol>
 </section>

 <section name="Setup for testing - adding the Staging repository for Maven builds">
   <p>
     If you want Maven to be able to find the artifacts in the staging repository during
     its build processing,
     follow the next instructions, and then add this additional parameter to your "mvn"
     commands: <code>-Pstaged-release</code>.
   </p>
   <p style="margin-left: 3em">This is sometimes needed to test new build tooling,
      for example.  The test would be done by (temporarily) updating some code to depend
      on the new version, and then trying to build it.  In this case, with the
      <code>-Pstaged-release</code> added, Maven would be able to find the staged
      artifacts.
   </p>
   <p>
     To enable Maven to find artifacts in the staging repository location:
     <ul>
         <li>Update your Maven "settings.xml" file
         located in the directory containing your local Maven repository;
     in Windows, this is c:\Documents and Settings\&lt;your-userid>\.m2\settings.xml.
     The idea is to add
     a repository spec called "staged-release" that points to the staging repository
     of interest. This
     changes for each staged release - the right url will be provided in the [VOTE] email).
     Here's a sample settings file, with just this profile element in it:
 <pre>
 &lt;settings xmlns="https://maven.apache.org/POM/4.0.0"
   xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
                       https://maven.apache.org/xsd/settings-1.0.0.xsd">

   &lt;profiles>
     &lt;profile>
       &lt;id>staged-release&lt;/id>
       &lt;repositories>
         &lt;repository>
           &lt;id>staged-release&lt;/id>
           &lt;url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/&lt;/url>
         &lt;/repository>
       &lt;/repositories>
       &lt;pluginRepositories>
         &lt;pluginRepository>
           &lt;id>staged-release&lt;/id>
           &lt;url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/&lt;/url>
         &lt;/pluginRepository>
       &lt;/pluginRepositories>
     &lt;/profile>
   &lt;/profiles>

 &lt;/settings>
 </pre>
     <p class="note">
       <b>Note:</b> The url element above is just a sample;
       each release will have its own unique staging repository name,
       which is provided in the [VOTE] email.
         Replace the .../orgapacheuima-xxxxxx with the correct url.
     </p>

   </li>
     </ul>
   </p>
 </section>


 </body>
 </document>
	<?xml version="1.0" encoding="UTF-8"?>

	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	https://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->
	<document>

	<properties>
	<title>Testing Release Candidates</title>
	<author email="dev@uima.apache.org">
	Apache UIMA Documentation Team</author>
	</properties>

	<body>

	<section name="Testing Release Candidates">
	<p>
	This page has information for testing release candidates.
	</p>
	<p>
	Prepare for testing by going to
	<a href="building-uima.html">building-uima</a>
	and doing the one-time setup, if you haven't done this already. This includes installing Maven 3.
	</p>
	</section>

	<section name="Overview">
	<p>See <a target="_blank" rel="noopener" href="https://www.apache.org/dev/release.html#what-must-every-release-contain">"What must be included in a release".</a>
	To approve a release, it is good to do the following tests:
	<ul>
	<li>svn export the SVN tag for the code, and compare this to the unzip of the source-release. These should be the same, except for some minor things;
	use your good judgement.</li>
	<li>Check building from source: In your local .m2, delete the files being built (a good thing is to
	delete the "uima" directory), then get the source-release, unzip it, and run mvn install at the top level, to see if it builds.</li>
	<li>Check that the license and notice files are present in the source and binary distributions, and that the binary distributions have license/notice parts
	incorporated into the top-level license/notice files for any included artifacts being distributed.</li>
	<li>Check that the Jars have appropriate license / notice files for things contained within them.</li>
	<li>When an Eclipse update site is being released, try installing that into a fresh unzip of Eclipse 3.7.2 or later, and then verify the functionality seems present.
	When installing, it should show the standard licensing boilerplate, that refers (like the Eclipse user agreement) to embedded license/notice files.</li>
	</ul>
	</p>

	</section>
	<section name="Testing a source-release">

	<ol>
	<li>Download the ....source-release.zip file from the staging repository, for the
	top-most released artifact. (Multimodule releases will have one top-level release artifact).
	</li>
	<li>Unzip.</li>
	<li>cd to the top level release artifact directory.</li>

	<li>Run
	<pre>mvn install</pre>
	to verify it builds from source.</li>

	<li>Inspect the unzipped source to verify license/notice files are in place.</li>
	<li>Run whatever further tests might be appropriate for the release.</li>
	</ol>
	</section>

	<section name="Setup for testing - adding the Staging repository for Maven builds">
	<p>
	If you want Maven to be able to find the artifacts in the staging repository during
	its build processing,
	follow the next instructions, and then add this additional parameter to your "mvn"
	commands: <code>-Pstaged-release</code>.
	</p>
	<p style="margin-left: 3em">This is sometimes needed to test new build tooling,
	for example. The test would be done by (temporarily) updating some code to depend
	on the new version, and then trying to build it. In this case, with the
	<code>-Pstaged-release</code> added, Maven would be able to find the staged
	artifacts.
	</p>
	<p>
	To enable Maven to find artifacts in the staging repository location:
	<ul>
	<li>Update your Maven "settings.xml" file
	located in the directory containing your local Maven repository;
	in Windows, this is c:\Documents and Settings\<your-userid>\.m2\settings.xml.
	The idea is to add
	a repository spec called "staged-release" that points to the staging repository
	of interest. This
	changes for each staged release - the right url will be provided in the [VOTE] email).
	Here's a sample settings file, with just this profile element in it:
	<pre>
	<settings xmlns="https://maven.apache.org/POM/4.0.0"
	xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
	https://maven.apache.org/xsd/settings-1.0.0.xsd">

	<profiles>
	<profile>
	<id>staged-release</id>
	<repositories>
	<repository>
	<id>staged-release</id>
	<url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/</url>
	</repository>
	</repositories>
	<pluginRepositories>
	<pluginRepository>
	<id>staged-release</id>
	<url>https://repository.apache.org/content/repositories/orgapacheuima-xxx/</url>
	</pluginRepository>
	</pluginRepositories>
	</profile>
	</profiles>

	</settings>
	</pre>
	<p class="note">
	<b>Note:</b> The url element above is just a sample;
	each release will have its own unique staging repository name,
	which is provided in the [VOTE] email.
	Replace the .../orgapacheuima-xxxxxx with the correct url.
	</p>

	</li>
	</ul>
	</p>
	</section>


	</body>
	</document>