You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by sc...@apache.org on 2009/09/16 19:28:05 UTC
svn commit: r815901 - in /incubator/uima/site/trunk/uima-website:
docs/distribution.html xdocs/distribution.xml
Author: schor
Date: Wed Sep 16 17:28:05 2009
New Revision: 815901
URL: http://svn.apache.org/viewvc?rev=815901&view=rev
Log:
UIMA-1575 document using maven to build eclipse update site.
Modified:
incubator/uima/site/trunk/uima-website/docs/distribution.html
incubator/uima/site/trunk/uima-website/xdocs/distribution.xml
Modified: incubator/uima/site/trunk/uima-website/docs/distribution.html
URL: http://svn.apache.org/viewvc/incubator/uima/site/trunk/uima-website/docs/distribution.html?rev=815901&r1=815900&r2=815901&view=diff
==============================================================================
--- incubator/uima/site/trunk/uima-website/docs/distribution.html (original)
+++ incubator/uima/site/trunk/uima-website/docs/distribution.html Wed Sep 16 17:28:05 2009
@@ -198,11 +198,15 @@
This will extract the source code from SVN, compile and run the tests, and finally build the
distribution artifacts.
</p>
- <p>The build process builds individual Jar files suitable for uploading into a maven repository, 2 assemblies
+ <p>The build process for base UIMA builds individual Jar files suitable for uploading into a maven repository, 2 assemblies
(one for the source and one for the binary distributions), and an Eclipse update site. The
individual Jar files are in the <code>target</code> directories of the individual projects they
belong to. The assemblies (source and binary) are in the <code>uimaj-distr/target</code> directory.
</p>
+ <p>
+ The build process for UIMA-AS and the Sandbox projects is similar. Both have assembly projects:
+ uima-as-distr and SandboxDistr.
+ </p>
<table class="subsectionTable">
<tr><td>
@@ -217,39 +221,50 @@
<blockquote class="subsectionBody">
<p>
The Eclipse update site build is somewhat unusual, because it accumulates releases over time
- from various UIMA projects. This is because we have just one update site (at the moment)
+ from various UIMA distributions. This is because we have just one update site (at the moment)
for all releases, for all components that want this service,
- such as the core UIMA and UIMA-AS (a sandbox project).
- </p>
- <p>
- The Eclipse update site is built in 2 phases. The first phase occurs during the normal maven
- builds of the project - this phase builds the Jars that constitute the plugins.
+ such as the core UIMA and UIMA-AS.
</p>
<p>
- The second phase occurs after a release is approved, and consists of several parts:
+ The Eclipse plugs are organized into Features. These each have a project, using the naming
+ convention of uimaj-eclipse-feature-xxxx. Currently we have 3 features:
<ul>
- <li>Any new Plugin Jars are packed</li>
- <li>The feature jars are generated</li>
- <li>The Site.xml is updated to include the any new components / versions</li>
- <li>The site digest is regenerated</li>
+ <li>uimaj-eclipse-feature-deployeditor (for the UIMA-AS editor for deployment descriptors)</li>
+ <li>uimaj-eclipse-feature-runtime (for other plugins, and for building RCP applications)</li>
+ <li>uimaj-eclipse-feature-tools (holds most of the UIMA Eclipse tooling</li>
</ul>
</p>
- <p>These steps are carried out by running the build.xml script with "ant" in the
- uimaj-eclipse-update-site project, after placing any new plugin jars
- from the approved release candidate in the "plugins" folder. The "plugins" folder should
- not have any other jars in it (other than the new ones which will be packed);
- the "features" folder is saved in SVN and accumulates the
- feature Jars for all the features/versions. The feature Jars do not actually contain any Java classes;
- the Jar format is just to consolidate and compress the file contents.
+ <p>Prior to building the update site, the feature sites need to be updated to reflect the
+ set of features for the current release. The build will create Jar files tagged with the
+ release number, for each updated feature.</p>
+ <p>
+ The Eclipse update site is built in 2 phases.
+ <ol>
+ <li>
+ <p>The first phase occurs during the normal maven
+ builds of the project - this phase builds the Jars that constitute the plugins.</p>
+ </li>
+ <li>
+ <p>
+ The second consists of several parts.
+ </p>
+ <p>The set of feature projects, uimaj-eclipse-feature-xxxxx, must all be updated for
+ the current release. Generally, only the <code>pom.xml</code> and <code>feature.xml</code> files will
+ need updating.</p>
+ <p>Update the uimaj-eclipse-update-site project for the release: the files <code>pom.xml</code>
+ and <code>site.xml</code>. Then execute the maven command <code>mvn install</code> on the uimaj-eclipse-update-site project.
+ The POM for this is an aggregator POM and will recursively invoke <code>install</code> on the uimaj-eclipse-feature-xxxxx
+ projects, to build their Jars.</p>
+
+ <p>The result of running <code>mvn install</code> will be a partial, but working Eclipse update site, located
+ in the project's target/eclipse-update-site directory. It is partial, because the real update site keeps
+ back level versions of the feature and plugin jars, while this site will only have jars for the current release.
+ When uploading to the distribution point after the release is approved, be sure to merge in those jars.
+ The feature Jars (in the uimaj-eclipse-update-site/features directory) for the new update site are checked into SVN,
+ for use by future builds.</p>
+ </li>
+ </ol>
</p>
- <p>
- The result of running the build.xml is a partial eclipse update site
- in the uimaj-eclipse-update-site project, in the <code>target/eclipse-update-site</code> directory.
- It is partial because it doesn't contain <b>all</b> the plugin jars from previously released versions.
- The official distribution place for the update site on www.apache.org will be updated by adding
- any new plugin and feature jars, and replacing the site.xml and digest files, with the ones in the
- <code>target/eclipse-update-site</code> directory.
- </p>
</blockquote>
</td></tr>
</table>
Modified: incubator/uima/site/trunk/uima-website/xdocs/distribution.xml
URL: http://svn.apache.org/viewvc/incubator/uima/site/trunk/uima-website/xdocs/distribution.xml?rev=815901&r1=815900&r2=815901&view=diff
==============================================================================
--- incubator/uima/site/trunk/uima-website/xdocs/distribution.xml (original)
+++ incubator/uima/site/trunk/uima-website/xdocs/distribution.xml Wed Sep 16 17:28:05 2009
@@ -58,52 +58,66 @@
This will extract the source code from SVN, compile and run the tests, and finally build the
distribution artifacts.
</p>
- <p>The build process builds individual Jar files suitable for uploading into a maven repository, 2 assemblies
+ <p>The build process for base UIMA builds individual Jar files suitable for uploading into a maven repository, 2 assemblies
(one for the source and one for the binary distributions), and an Eclipse update site. The
individual Jar files are in the <code>target</code> directories of the individual projects they
belong to. The assemblies (source and binary) are in the <code>uimaj-distr/target</code> directory.
- </p>
+ </p>
+
+ <p>
+ The build process for UIMA-AS and the Sandbox projects is similar. Both have assembly projects:
+ uima-as-distr and SandboxDistr.
+ </p>
<subsection name="Eclipse Update Site">
<p>
The Eclipse update site build is somewhat unusual, because it accumulates releases over time
- from various UIMA projects. This is because we have just one update site (at the moment)
+ from various UIMA distributions. This is because we have just one update site (at the moment)
for all releases, for all components that want this service,
- such as the core UIMA and UIMA-AS (a sandbox project).
- </p>
- <p>
- The Eclipse update site is built in 2 phases. The first phase occurs during the normal maven
- builds of the project - this phase builds the Jars that constitute the plugins.
+ such as the core UIMA and UIMA-AS.
</p>
<p>
- The second phase occurs after a release is approved, and consists of several parts:
+ The Eclipse plugs are organized into Features. These each have a project, using the naming
+ convention of uimaj-eclipse-feature-xxxx. Currently we have 3 features:
<ul>
- <li>Any new Plugin Jars are packed</li>
- <li>The feature jars are generated</li>
- <li>The Site.xml is updated to include the any new components / versions</li>
- <li>The site digest is regenerated</li>
- </ul>
- </p>
- <p>These steps are carried out by running the build.xml script with "ant" in the
- uimaj-eclipse-update-site project, after placing any new plugin jars
- from the approved release candidate in the "plugins" folder. The "plugins" folder should
- not have any other jars in it (other than the new ones which will be packed);
- the "features" folder is saved in SVN and accumulates the
- feature Jars for all the features/versions. The feature Jars do not actually contain any Java classes;
- the Jar format is just to consolidate and compress the file contents.
- </p>
-
- <p>
- The result of running the build.xml is a partial eclipse update site
- in the uimaj-eclipse-update-site project, in the <code>target/eclipse-update-site</code> directory.
- It is partial because it doesn't contain <b>all</b> the plugin jars from previously released versions.
- The official distribution place for the update site on www.apache.org will be updated by adding
- any new plugin and feature jars, and replacing the site.xml and digest files, with the ones in the
- <code>target/eclipse-update-site</code> directory.
- </p>
-
+ <li>uimaj-eclipse-feature-deployeditor (for the UIMA-AS editor for deployment descriptors)</li>
+ <li>uimaj-eclipse-feature-runtime (for other plugins, and for building RCP applications)</li>
+ <li>uimaj-eclipse-feature-tools (holds most of the UIMA Eclipse tooling</li>
+ </ul>
+ </p>
+ <p>Prior to building the update site, the feature sites need to be updated to reflect the
+ set of features for the current release. The build will create Jar files tagged with the
+ release number, for each updated feature.</p>
+ <p>
+ The Eclipse update site is built in 2 phases.
+ <ol>
+ <li>
+ <p>The first phase occurs during the normal maven
+ builds of the project - this phase builds the Jars that constitute the plugins.</p>
+ </li>
+ <li>
+ <p>
+ The second consists of several parts.
+ </p>
+ <p>The set of feature projects, uimaj-eclipse-feature-xxxxx, must all be updated for
+ the current release. Generally, only the <code>pom.xml</code> and <code>feature.xml</code> files will
+ need updating.</p>
+ <p>Update the uimaj-eclipse-update-site project for the release: the files <code>pom.xml</code>
+ and <code>site.xml</code>. Then execute the maven command <code>mvn install</code> on the uimaj-eclipse-update-site project.
+ The POM for this is an aggregator POM and will recursively invoke <code>install</code> on the uimaj-eclipse-feature-xxxxx
+ projects, to build their Jars.</p>
+
+ <p>The result of running <code>mvn install</code> will be a partial, but working Eclipse update site, located
+ in the project's target/eclipse-update-site directory. It is partial, because the real update site keeps
+ back level versions of the feature and plugin jars, while this site will only have jars for the current release.
+ When uploading to the distribution point after the release is approved, be sure to merge in those jars.
+ The feature Jars (in the uimaj-eclipse-update-site/features directory) for the new update site are checked into SVN,
+ for use by future builds.</p>
+ </li>
+ </ol>
+ </p>
</subsection>
</section>