You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2010/09/05 23:13:29 UTC
[VOTE] Release build poms incorporating change to docbkx 2.0.11 version
This version upgrade removes the need for special one-time setups to get docbkx
to work :-)
Updated: parent-pom-docbook - to version 3. Jira fixed:
https://issues.apache.org/jira/browse/UIMA-1862
Also updated and being released: parent poms that refer to this as a parent, to
refer to the new version.
The release artifacts are staged in the Apache Nexus repository. Unfortunately,
I "closed" the initial staging repository leaving out one of the parent-poms so
I had to open another staging repository just for it. Please consider this
release to consist of both staging repositories:
https://repository.apache.org/content/repositories/orgapacheuima-033/
https://repository.apache.org/content/repositories/orgapacheuima-034/
To enable you to test this, please follow the same procedures as before for
testing build poms:
Suggested way to test: add this to your maven "settings" in the <profiles> section:
<profile>
<id>staged-release</id>
<repositories>
<repository>
<id>staged-release</id>
<url>https://repository.apache.org/content/repositories/orgapacheuima-033/</url>
</repository>
<repository>
<id>staged-release2</id>
<url>https://repository.apache.org/content/repositories/orgapacheuima-034/</url>
</repository>
</repositories>
</profile>
For testing, I've gone ahead and updated the trunk projects in uimaj that build
docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to this new
version. So a good test is to
cd ..../aggregate-uimaj-docbooks
mvn clean install -Pstaged-release
and
cd ..../PearPackagingMavenPlugin
mvn clean install -Pstaged-release
Of course, any other project (e.g., sandbox projects) that have docbooks, can
(and probably should) be used to test this - but for those, please update the
version of the parent poms to specify the poms being released (version 2 needs
to be changed to version 3), and include the -Pstaged-release parameter to let
maven use the artifacts from the staging repositories.
Also, please inspect the release artifacts to insure they have the proper
license /notice files, and can be built from the source-release zips.
Vote open for 72 hours.
Thanks for your vote; with this change, we're removing one of the onerous
one-time-setup steps (I'll update the website as soon as this is approved).
-Marshall
Re: building source-release.zip - was: [VOTE] Release build poms
incorporating change to docbkx 2.0.11 version
Posted by Marshall Schor <ms...@schor.com>.
Here's more details on how the source-release.zip is built (for those who
really want to know ... )
Our build process follows the standard Apache Maven build processes, and uses
the common Apache-wide "super pom":
The source release zip artifact (e.g. xxx-version-source-release.zip where xxx
= the maven artifactId) is created by the Apache super pom during the release
process. Our parent-pom-top/pom.xml has, as a parent, the Apache common super
pom, http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom .
In that pom, there is a section within a profile named "apache-release"; here
are the relevant parts:
<profiles>
<!-- START SNIPPET: release-profile -->
<profile>
<id>apache-release</id>
<build>
<plugins>
<!-- Create a source-release artifact that contains the fully buildable
project directory source structure. This is the artifact which is
the official subject of any release vote. -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.apache.apache.resources</groupId>
<artifactId>apache-source-release-assembly-descriptor</artifactId>
<version>1.0.2</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>source-release-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
<descriptorRefs>
<descriptorRef>${sourceReleaseAssemblyDescriptor}</descriptorRef>
</descriptorRefs>
<tarLongFileFormat>gnu</tarLongFileFormat>
</configuration>
</execution>
</executions>
</plugin>
... omitted sections ...
</plugins>
</build>
</profile>
<!-- END SNIPPET: release-profile -->
</profiles>
To understand how this works, the assembly plugin uses the
${sourceReleaseAssemblyDescriptor} as a "built-in" descriptor. Only, it's not
really built-in. The assembly plugin looks up built-in descriptors following a
naming convention, in the classpath. The <dependency> element inside the
<plugin> element adds the necessary thing to the classpath, so this is like a
"custom" built-in.
Here's the assembly descriptor that it uses (from
http://repo1.maven.org/maven2/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.2/
- it's inside the jar artifact - you have to unzip it to find it...)
<assembly>
<id>source-release</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<!-- main project directory structure -->
<fileSet>
<directory>.</directory>
<outputDirectory>/</outputDirectory>
<useDefaultExcludes>true</useDefaultExcludes>
<excludes>
<!-- build output -->
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/).*${project.build.directory}.*]</exclude>
<!-- NOTE: Most of the following excludes should not be required
if the standard release process is followed. This is because the
release plugin checks out project sources into a location like
target/checkout, then runs the build from there. The result is
a source-release archive that comes from a pretty clean directory
structure.
HOWEVER, if the release plugin is configured to run extra goals
or generate a project website, it's definitely possible that some
of these files will be present. So, it's safer to exclude them.
-->
<!-- IDEs -->
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?maven-eclipse\.xml]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.project]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.classpath]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?[^/]*\.iws]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?[^/]*\.ipr]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?[^/]*\.iml]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.settings(/.*)?]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.externalToolBuilders(/.*)?]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.deployables(/.*)?]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?\.wtpmodules(/.*)?]</exclude>
<!-- misc -->
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?cobertura\.ser]</exclude>
<!-- release-plugin temp files -->
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?pom\.xml\.releaseBackup]</exclude>
<exclude>%regex[(?!((?!${project.build.directory}/)[^/]+/)*src/)(.*/)?release\.properties]</exclude>
</excludes>
</fileSet>
<!-- license, readme, etc. calculated at build time -->
<fileSet>
<directory>${project.build.directory}/maven-shared-archive-resources/META-INF</directory>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
</assembly>
Because this is in the apache-release profile, which is not activated normally,
the source release zip is normally not built. The apache release plugin is
configured to activate this profile when a release is being performed.
-Marshall
Re: building source-release.zip - was: [VOTE] Release build poms
incorporating change to docbkx 2.0.11 version
Posted by Marshall Schor <ms...@schor.com>.
Hi,
On 9/6/2010 3:09 AM, Jörn Kottmann wrote:
> ...
>> Also, please inspect the release artifacts to insure they have the proper
>> license /notice files, and can be built from the source-release zips.
>>
>
>
> Where must the license and notice files be placed ? After building the
> Pear Packaging Maven Plugin jar file it contained the two files
> in the META-INF folder.
The license and notice files for Jar artifacts go in the META-INF folder, so
this is correct. However, the thing to be checking is not the Pear Packaging
Maven Plugin - it's not (yet) being released, but rather the artifacts being
released (via downloading them from the staging repo and checking them :-) ).
>
> How can the source release zip be created ? Do I have to build the uima base
> source distribution or is there a way to build it for an individual project ?
The source-release.zip files are created by the Apache shared common super POM,
when the apache-release profile is activated (which happens automagically when
the maven release plugin does the release). So you can see these files in the
staging repository.
If you want to build them for another artifact, not as part of the release
process, it would probably work to:
1) cd to the project you want to build this for
2) run the command:
mvn package -Papache-release
This probably will also cause checksums and PGP signing to be invoked, though.
-Marshall
>
> Jörn
>
>
Re: [VOTE] Release build poms incorporating change to docbkx 2.0.11
version
Posted by Jörn Kottmann <ko...@gmail.com>.
On 9/5/10 11:13 PM, Marshall Schor wrote:
> This version upgrade removes the need for special one-time setups to get docbkx
> to work :-)
>
> Updated: parent-pom-docbook - to version 3. Jira fixed:
> https://issues.apache.org/jira/browse/UIMA-1862
>
> Also updated and being released: parent poms that refer to this as a parent, to
> refer to the new version.
>
> The release artifacts are staged in the Apache Nexus repository. Unfortunately,
> I "closed" the initial staging repository leaving out one of the parent-poms so
> I had to open another staging repository just for it. Please consider this
> release to consist of both staging repositories:
>
> https://repository.apache.org/content/repositories/orgapacheuima-033/
>
> https://repository.apache.org/content/repositories/orgapacheuima-034/
>
> To enable you to test this, please follow the same procedures as before for
> testing build poms:
> Suggested way to test: add this to your maven "settings" in the<profiles> section:
>
> <profile>
> <id>staged-release</id>
> <repositories>
> <repository>
> <id>staged-release</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-033/</url>
> </repository>
> <repository>
> <id>staged-release2</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-034/</url>
> </repository>
> </repositories>
> </profile>
>
> For testing, I've gone ahead and updated the trunk projects in uimaj that build
> docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to this new
> version. So a good test is to
>
> cd ..../aggregate-uimaj-docbooks
> mvn clean install -Pstaged-release
>
> and
>
> cd ..../PearPackagingMavenPlugin
> mvn clean install -Pstaged-release
>
> Of course, any other project (e.g., sandbox projects) that have docbooks, can
> (and probably should) be used to test this - but for those, please update the
> version of the parent poms to specify the poms being released (version 2 needs
> to be changed to version 3), and include the -Pstaged-release parameter to let
> maven use the artifacts from the staging repositories.
>
> Also, please inspect the release artifacts to insure they have the proper
> license /notice files, and can be built from the source-release zips.
>
Where must the license and notice files be placed ? After building the
Pear Packaging Maven Plugin jar file it contained the two files
in the META-INF folder.
How can the source release zip be created ? Do I have to build the uima
base
source distribution or is there a way to build it for an individual
project ?
Jörn
Re: [VOTE] Release build poms incorporating change to docbkx 2.0.11
version
Posted by Jörn Kottmann <ko...@gmail.com>.
+1 to release also from me.
Jörn
On 9/5/10 11:13 PM, Marshall Schor wrote:
> This version upgrade removes the need for special one-time setups to get docbkx
> to work :-)
>
> Updated: parent-pom-docbook - to version 3. Jira fixed:
> https://issues.apache.org/jira/browse/UIMA-1862
>
> Also updated and being released: parent poms that refer to this as a parent, to
> refer to the new version.
>
> The release artifacts are staged in the Apache Nexus repository. Unfortunately,
> I "closed" the initial staging repository leaving out one of the parent-poms so
> I had to open another staging repository just for it. Please consider this
> release to consist of both staging repositories:
>
> https://repository.apache.org/content/repositories/orgapacheuima-033/
>
> https://repository.apache.org/content/repositories/orgapacheuima-034/
>
> To enable you to test this, please follow the same procedures as before for
> testing build poms:
> Suggested way to test: add this to your maven "settings" in the<profiles> section:
>
> <profile>
> <id>staged-release</id>
> <repositories>
> <repository>
> <id>staged-release</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-033/</url>
> </repository>
> <repository>
> <id>staged-release2</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-034/</url>
> </repository>
> </repositories>
> </profile>
>
> For testing, I've gone ahead and updated the trunk projects in uimaj that build
> docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to this new
> version. So a good test is to
>
> cd ..../aggregate-uimaj-docbooks
> mvn clean install -Pstaged-release
>
> and
>
> cd ..../PearPackagingMavenPlugin
> mvn clean install -Pstaged-release
>
> Of course, any other project (e.g., sandbox projects) that have docbooks, can
> (and probably should) be used to test this - but for those, please update the
> version of the parent poms to specify the poms being released (version 2 needs
> to be changed to version 3), and include the -Pstaged-release parameter to let
> maven use the artifacts from the staging repositories.
>
> Also, please inspect the release artifacts to insure they have the proper
> license /notice files, and can be built from the source-release zips.
>
> Vote open for 72 hours.
>
> Thanks for your vote; with this change, we're removing one of the onerous
> one-time-setup steps (I'll update the website as soon as this is approved).
>
> -Marshall
>
>
[VOTE][RESULT] Release build poms incorporating change to docbkx
2.0.11 version
Posted by Marshall Schor <ms...@schor.com>.
The vote passes with 3 +1's and no other votes:
+1 Marshall Schor
+1 Jörn Kottmann
+1 Tommaso Teofili
Thanks for voting! I'll do the next release steps, and update the
one-time-setup webpages.
-Marshall
On 9/5/2010 5:13 PM, Marshall Schor wrote:
> This version upgrade removes the need for special one-time setups to get docbkx
> to work :-)
>
> Updated: parent-pom-docbook - to version 3. Jira fixed:
> https://issues.apache.org/jira/browse/UIMA-1862
>
> Also updated and being released: parent poms that refer to this as a parent, to
> refer to the new version.
>
> The release artifacts are staged in the Apache Nexus repository. Unfortunately,
> I "closed" the initial staging repository leaving out one of the parent-poms so
> I had to open another staging repository just for it. Please consider this
> release to consist of both staging repositories:
>
> https://repository.apache.org/content/repositories/orgapacheuima-033/
>
> https://repository.apache.org/content/repositories/orgapacheuima-034/
>
> To enable you to test this, please follow the same procedures as before for
> testing build poms:
> Suggested way to test: add this to your maven "settings" in the <profiles> section:
>
> <profile>
> <id>staged-release</id>
> <repositories>
> <repository>
> <id>staged-release</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-033/</url>
> </repository>
> <repository>
> <id>staged-release2</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-034/</url>
> </repository>
> </repositories>
> </profile>
>
> For testing, I've gone ahead and updated the trunk projects in uimaj that build
> docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to this new
> version. So a good test is to
>
> cd ..../aggregate-uimaj-docbooks
> mvn clean install -Pstaged-release
>
> and
>
> cd ..../PearPackagingMavenPlugin
> mvn clean install -Pstaged-release
>
> Of course, any other project (e.g., sandbox projects) that have docbooks, can
> (and probably should) be used to test this - but for those, please update the
> version of the parent poms to specify the poms being released (version 2 needs
> to be changed to version 3), and include the -Pstaged-release parameter to let
> maven use the artifacts from the staging repositories.
>
> Also, please inspect the release artifacts to insure they have the proper
> license /notice files, and can be built from the source-release zips.
>
> Vote open for 72 hours.
>
> Thanks for your vote; with this change, we're removing one of the onerous
> one-time-setup steps (I'll update the website as soon as this is approved).
>
> -Marshall
>
>
>
>
Re: [VOTE] Release build poms incorporating change to docbkx 2.0.11 version
Posted by Tommaso Teofili <to...@gmail.com>.
+1 to release.
Tommaso
2010/9/7 Marshall Schor <ms...@schor.com>
> +1 to release.
>
> I downloaded and built all of these artifacts on a separate computer (a
> Mac). I
> did find one "cosmetic" error, which doesn't affect the function. The
> component
> parent-pom-eclipse-plugins-ibm-notice is running part of its parent pom's
> build
> process intended only for actual eclipse plugins - this part renames the
> build
> artifact to follow OSGi naming rules.
>
> Because of this, the zip file that is made for source-release creates a top
> level folder with a name parent-pom-eclipse-plugins-ibm-notice_3.0.0. This
> doesn't hurt anything (other than cause some confusion). It's easily
> fixable by
> including a special 0-length file named
> "marker-file-identifying-parent-pom-eclipse-plugins" which, if present,
> prevents
> the build process from running those steps. So I'll fix that and it will
> get
> picked up with the next release (at some time in the future)...
>
> I also confirmed that with the new build tooling, the docbooks in uimaj
> built.
>
> As a bonus, I did all this on a fresh install of Helios (Eclipse 3.6) where
> I
> installed a snapshot build of the m2eclipse; that worked fine. For those
> interested, I got the snapshot from here:
>
> https://repository.sonatype.org/content/sites/forge-sites/m2e/0.11.1/N/0.11.1.201009041932
>
> -Marshall
>
> On 9/5/2010 5:13 PM, Marshall Schor wrote:
> > This version upgrade removes the need for special one-time setups to get
> docbkx
> > to work :-)
> >
> > Updated: parent-pom-docbook - to version 3. Jira fixed:
> > https://issues.apache.org/jira/browse/UIMA-1862
> >
> > Also updated and being released: parent poms that refer to this as a
> parent, to
> > refer to the new version.
> >
> > The release artifacts are staged in the Apache Nexus repository.
> Unfortunately,
> > I "closed" the initial staging repository leaving out one of the
> parent-poms so
> > I had to open another staging repository just for it. Please consider
> this
> > release to consist of both staging repositories:
> >
> > https://repository.apache.org/content/repositories/orgapacheuima-033/
> >
> > https://repository.apache.org/content/repositories/orgapacheuima-034/
> >
> > To enable you to test this, please follow the same procedures as before
> for
> > testing build poms:
> > Suggested way to test: add this to your maven "settings" in the
> <profiles> section:
> >
> > <profile>
> > <id>staged-release</id>
> > <repositories>
> > <repository>
> > <id>staged-release</id>
> > <url>
> https://repository.apache.org/content/repositories/orgapacheuima-033/
> </url>
> > </repository>
> > <repository>
> > <id>staged-release2</id>
> > <url>
> https://repository.apache.org/content/repositories/orgapacheuima-034/
> </url>
> > </repository>
> > </repositories>
> > </profile>
> >
> > For testing, I've gone ahead and updated the trunk projects in uimaj that
> build
> > docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to
> this new
> > version. So a good test is to
> >
> > cd ..../aggregate-uimaj-docbooks
> > mvn clean install -Pstaged-release
> >
> > and
> >
> > cd ..../PearPackagingMavenPlugin
> > mvn clean install -Pstaged-release
> >
> > Of course, any other project (e.g., sandbox projects) that have docbooks,
> can
> > (and probably should) be used to test this - but for those, please update
> the
> > version of the parent poms to specify the poms being released (version 2
> needs
> > to be changed to version 3), and include the -Pstaged-release parameter
> to let
> > maven use the artifacts from the staging repositories.
> >
> > Also, please inspect the release artifacts to insure they have the proper
> > license /notice files, and can be built from the source-release zips.
> >
> > Vote open for 72 hours.
> >
> > Thanks for your vote; with this change, we're removing one of the onerous
> > one-time-setup steps (I'll update the website as soon as this is
> approved).
> >
> > -Marshall
> >
> >
> >
> >
>
Re: [VOTE] Release build poms incorporating change to docbkx 2.0.11
version
Posted by Marshall Schor <ms...@schor.com>.
+1 to release.
I downloaded and built all of these artifacts on a separate computer (a Mac). I
did find one "cosmetic" error, which doesn't affect the function. The component
parent-pom-eclipse-plugins-ibm-notice is running part of its parent pom's build
process intended only for actual eclipse plugins - this part renames the build
artifact to follow OSGi naming rules.
Because of this, the zip file that is made for source-release creates a top
level folder with a name parent-pom-eclipse-plugins-ibm-notice_3.0.0. This
doesn't hurt anything (other than cause some confusion). It's easily fixable by
including a special 0-length file named
"marker-file-identifying-parent-pom-eclipse-plugins" which, if present, prevents
the build process from running those steps. So I'll fix that and it will get
picked up with the next release (at some time in the future)...
I also confirmed that with the new build tooling, the docbooks in uimaj built.
As a bonus, I did all this on a fresh install of Helios (Eclipse 3.6) where I
installed a snapshot build of the m2eclipse; that worked fine. For those
interested, I got the snapshot from here:
https://repository.sonatype.org/content/sites/forge-sites/m2e/0.11.1/N/0.11.1.201009041932
-Marshall
On 9/5/2010 5:13 PM, Marshall Schor wrote:
> This version upgrade removes the need for special one-time setups to get docbkx
> to work :-)
>
> Updated: parent-pom-docbook - to version 3. Jira fixed:
> https://issues.apache.org/jira/browse/UIMA-1862
>
> Also updated and being released: parent poms that refer to this as a parent, to
> refer to the new version.
>
> The release artifacts are staged in the Apache Nexus repository. Unfortunately,
> I "closed" the initial staging repository leaving out one of the parent-poms so
> I had to open another staging repository just for it. Please consider this
> release to consist of both staging repositories:
>
> https://repository.apache.org/content/repositories/orgapacheuima-033/
>
> https://repository.apache.org/content/repositories/orgapacheuima-034/
>
> To enable you to test this, please follow the same procedures as before for
> testing build poms:
> Suggested way to test: add this to your maven "settings" in the <profiles> section:
>
> <profile>
> <id>staged-release</id>
> <repositories>
> <repository>
> <id>staged-release</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-033/</url>
> </repository>
> <repository>
> <id>staged-release2</id>
> <url>https://repository.apache.org/content/repositories/orgapacheuima-034/</url>
> </repository>
> </repositories>
> </profile>
>
> For testing, I've gone ahead and updated the trunk projects in uimaj that build
> docbooks (our 4 "books" plus the PearPackagingMavenPlugin) to refer to this new
> version. So a good test is to
>
> cd ..../aggregate-uimaj-docbooks
> mvn clean install -Pstaged-release
>
> and
>
> cd ..../PearPackagingMavenPlugin
> mvn clean install -Pstaged-release
>
> Of course, any other project (e.g., sandbox projects) that have docbooks, can
> (and probably should) be used to test this - but for those, please update the
> version of the parent poms to specify the poms being released (version 2 needs
> to be changed to version 3), and include the -Pstaged-release parameter to let
> maven use the artifacts from the staging repositories.
>
> Also, please inspect the release artifacts to insure they have the proper
> license /notice files, and can be built from the source-release zips.
>
> Vote open for 72 hours.
>
> Thanks for your vote; with this change, we're removing one of the onerous
> one-time-setup steps (I'll update the website as soon as this is approved).
>
> -Marshall
>
>
>
>