You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Tommaso Teofili <to...@gmail.com> on 2010/06/26 17:57:09 UTC
Re: [VOTE] [POSSIBLE ISSUE] Release of build parent poms and tools,
version 1
>From my point of view this is not blocking for the current release (so I am
+1) but maybe it could make sense to abandon the parent-poms directory on
SVN and have a cleaner structure, but I don't know if this parent-poms
directory has to be there for some reason, maybe Marshall knows it better
:-).
Tommaso
2010/6/25 Marshall Schor <ms...@schor.com>
> I did one more test, which was to get the "source-release" artifact
> assembly and see if I could build the artifacts from it. For the
> multi-module project "aggregate-parent-poms", the source-release
> artifact is aggregate-parent-poms-1-source-release.zip.
>
> I unzipped that and found it generated a layout that's slightly
> different from SVN. Because of this, the relative path to the <modules>
> is missing the .../parent-poms/... directory, found in SVN. So, because
> of this, doing mvn install on the aggregate-parent-poms project unzipped
> here, fails.
>
> If you edit the <modules> section to remove the .../parent-poms/...
> directory, mvn install works.
>
> So, the question is: is this a serious enough defect to warrant redoing
> this release? I don't think so. Here are my reasons:
>
> 1) The aggregate-parent-poms project is there for 2 reasons:
> a) to make building (and releasing) a bunch of the build artifacts in
> one go, possible, and
> b) to climb the learning curve on creating multi-module releases using
> the release plugin
>
> 2) After this release, I suspect we will not be releasing all of these
> at once, very often, but rather, just change those that need changing,
> individually.
>
> If we were to redo this, I would abandon the parent-poms directory in
> SVN, going back to the more "vanilla" directory structure, which would
> match what the assembly descriptor makes for multi-module projects.
>
> So I'm a +1 for the release, but if others think we should fix this
> before proceeding, I'll be happy to be over-ruled.
>
> Please express your opinion(s) :-)
>
> -Marshall
>
>
>
> On 6/25/2010 10:55 AM, Tommaso Teofili wrote:
> > +1
> > Tommaso
> >
> > 2010/6/25 Jörn Kottmann <ko...@gmail.com>
> >
> >
> >> Marshall Schor wrote:
> >>
> >>
> >>> The way we use Maven has been realigned to conform with more
> >>> conventional ways of using Maven and best practices. This includes
> >>> using the common Apache Release parent POM, the maven release plugin, a
> >>> maven plugin for running the docbook processing, and many other
> >>> improvements.
> >>>
> >>> The top parent pom for uima projects is already released (at version
> >>> 2). This release is for the remaining build tools and parent poms, and
> >>> is at version 1.
> >>>
> >>> Jira's fixed:
> >>>
> >>>
> >>> Sub-task
> >>>
> >>> * [UIMA-1757 <https://issues.apache.org/jira/browse/UIMA-1757>] -
> >>> use docbkx to create docbooks in place of current docbook tools
> >>> project
> >>> * [UIMA-1758 <https://issues.apache.org/jira/browse/UIMA-1758>] -
> >>> remove dependency on checked-out other projects
> >>> * [UIMA-1759 <https://issues.apache.org/jira/browse/UIMA-1759>] -
> >>> make project versioning more conventional
> >>> * [UIMA-1763 <https://issues.apache.org/jira/browse/UIMA-1763>] -
> >>> Switch to using Nexus for releasing
> >>>
> >>>
> >>> Bug
> >>>
> >>> * [UIMA-1051 <https://issues.apache.org/jira/browse/UIMA-1051>] -
> >>> doc build not working on Linux
> >>> * [UIMA-1805 <https://issues.apache.org/jira/browse/UIMA-1805>] -
> >>> change aggregate for build projects version to follow version
> >>> convention for those
> >>> * [UIMA-1806 <https://issues.apache.org/jira/browse/UIMA-1806>] -
> >>> fixes for releasing, in build poms
> >>> * [UIMA-1813 <https://issues.apache.org/jira/browse/UIMA-1813>] -
> >>> aggregate parent pom build fails rat test
> >>>
> >>>
> >>> Improvement
> >>>
> >>> * [UIMA-1814 <https://issues.apache.org/jira/browse/UIMA-1814>] -
> >>> Try making release:prepare work with all build projects by adding
> >>> in relative-path
> >>>
> >>>
> >>> Task
> >>>
> >>> * [UIMA-1755 <https://issues.apache.org/jira/browse/UIMA-1755>] -
> >>> Improve Maven build
> >>> * [UIMA-1816 <https://issues.apache.org/jira/browse/UIMA-1816>] -
> >>> update parent-pom-top references to version 2
> >>>
> >>>
> >>>
> >>> The release is staged here:
> >>> https://repository.apache.org/content/repositories/orgapacheuima-010/
> >>> 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-010/
> >>> </url>
> >>> </repository>
> >>> </repositories>
> >>> </profile>
> >>>
> >>> Please verify this by changing references to 1-SNAPSHOT versions of the
> >>> build artifacts (except the parent-pom-top which is at version 2, and
> >>> uima-docbook-olink project, which is not being released) to version 1
> >>> (without the SNAPSHOT), and see if things build, using the command
> >>>
> >>> mvn install -Pstaged-release
> >>>
> >>> More background on this approach is here:
> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Also, please inspect the release artifacts to insure they have the
> >>> proper license /notice files.
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>>
> >>>
> >>>
> >> +1
> >>
> >> Jörn
> >>
> >>
> >
>
Re: [VOTE] [POSSIBLE ISSUE] Release of build parent poms and tools,
version 1
Posted by Marshall Schor <ms...@schor.com>.
After thinking about this issue for a couple of days, I think I see a
way to fix the pom of the aggregate so that it builds the right
structure for the source-release zip.
Unless someone objects, I'm going to not release version 1 of these
things, and will now (following Jukka's advice) make version 2, with
that fix, which I will test first :-).
I'll look for responses tomorrow AM and if no objections, will proceed
in this fashion.
-Marshall (apologizing for taking so long to get our first
non-incubator release out the door).
On 6/26/2010 6:19 PM, Marshall Schor wrote:
> The parent-poms directory doesn't need to be there. I put it there,
> just to "organize" all the parent poms under one directory, to keep
> track of them :-).
>
> The cause is, as usual, rooted in some discord between what is
> programmed into Maven plugins as "conventions", and what the actual
> directory layout is.
>
> In this case, the plugin is the "assembly" plugin, and the feature I'm
> using is the <moduleSets>, which picks of all of the sub modules and
> gets their sources (obtained by whatever path the module elements
> specify), and puts them all into a "flat" structure.
>
> Another fix for this would be to figure out how to build a
> source-release zip file that includes the modules, but is guaranteed to
> be a (filtered) copy of the exact SVN layout. The filter would be
> because only those projects listed in the <modules> section would be
> included, along with any directories needed upto some (required) common
> super directory of all the <modules>. I think this would require a
> custom plugin, though.
>
>
> -Marshall
>
>
>
> On 6/26/2010 11:57 AM, Tommaso Teofili wrote:
>
>> >From my point of view this is not blocking for the current release (so I am
>> +1) but maybe it could make sense to abandon the parent-poms directory on
>> SVN and have a cleaner structure, but I don't know if this parent-poms
>> directory has to be there for some reason, maybe Marshall knows it better
>> :-).
>> Tommaso
>>
>> 2010/6/25 Marshall Schor <ms...@schor.com>
>>
>>
>>
>>> I did one more test, which was to get the "source-release" artifact
>>> assembly and see if I could build the artifacts from it. For the
>>> multi-module project "aggregate-parent-poms", the source-release
>>> artifact is aggregate-parent-poms-1-source-release.zip.
>>>
>>> I unzipped that and found it generated a layout that's slightly
>>> different from SVN. Because of this, the relative path to the <modules>
>>> is missing the .../parent-poms/... directory, found in SVN. So, because
>>> of this, doing mvn install on the aggregate-parent-poms project unzipped
>>> here, fails.
>>>
>>> If you edit the <modules> section to remove the .../parent-poms/...
>>> directory, mvn install works.
>>>
>>> So, the question is: is this a serious enough defect to warrant redoing
>>> this release? I don't think so. Here are my reasons:
>>>
>>> 1) The aggregate-parent-poms project is there for 2 reasons:
>>> a) to make building (and releasing) a bunch of the build artifacts in
>>> one go, possible, and
>>> b) to climb the learning curve on creating multi-module releases using
>>> the release plugin
>>>
>>> 2) After this release, I suspect we will not be releasing all of these
>>> at once, very often, but rather, just change those that need changing,
>>> individually.
>>>
>>> If we were to redo this, I would abandon the parent-poms directory in
>>> SVN, going back to the more "vanilla" directory structure, which would
>>> match what the assembly descriptor makes for multi-module projects.
>>>
>>> So I'm a +1 for the release, but if others think we should fix this
>>> before proceeding, I'll be happy to be over-ruled.
>>>
>>> Please express your opinion(s) :-)
>>>
>>> -Marshall
>>>
>>>
>>>
>>> On 6/25/2010 10:55 AM, Tommaso Teofili wrote:
>>>
>>>
>>>> +1
>>>> Tommaso
>>>>
>>>> 2010/6/25 Jörn Kottmann <ko...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>>> Marshall Schor wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The way we use Maven has been realigned to conform with more
>>>>>> conventional ways of using Maven and best practices. This includes
>>>>>> using the common Apache Release parent POM, the maven release plugin, a
>>>>>> maven plugin for running the docbook processing, and many other
>>>>>> improvements.
>>>>>>
>>>>>> The top parent pom for uima projects is already released (at version
>>>>>> 2). This release is for the remaining build tools and parent poms, and
>>>>>> is at version 1.
>>>>>>
>>>>>> Jira's fixed:
>>>>>>
>>>>>>
>>>>>> Sub-task
>>>>>>
>>>>>> * [UIMA-1757 <https://issues.apache.org/jira/browse/UIMA-1757>] -
>>>>>> use docbkx to create docbooks in place of current docbook tools
>>>>>> project
>>>>>> * [UIMA-1758 <https://issues.apache.org/jira/browse/UIMA-1758>] -
>>>>>> remove dependency on checked-out other projects
>>>>>> * [UIMA-1759 <https://issues.apache.org/jira/browse/UIMA-1759>] -
>>>>>> make project versioning more conventional
>>>>>> * [UIMA-1763 <https://issues.apache.org/jira/browse/UIMA-1763>] -
>>>>>> Switch to using Nexus for releasing
>>>>>>
>>>>>>
>>>>>> Bug
>>>>>>
>>>>>> * [UIMA-1051 <https://issues.apache.org/jira/browse/UIMA-1051>] -
>>>>>> doc build not working on Linux
>>>>>> * [UIMA-1805 <https://issues.apache.org/jira/browse/UIMA-1805>] -
>>>>>> change aggregate for build projects version to follow version
>>>>>> convention for those
>>>>>> * [UIMA-1806 <https://issues.apache.org/jira/browse/UIMA-1806>] -
>>>>>> fixes for releasing, in build poms
>>>>>> * [UIMA-1813 <https://issues.apache.org/jira/browse/UIMA-1813>] -
>>>>>> aggregate parent pom build fails rat test
>>>>>>
>>>>>>
>>>>>> Improvement
>>>>>>
>>>>>> * [UIMA-1814 <https://issues.apache.org/jira/browse/UIMA-1814>] -
>>>>>> Try making release:prepare work with all build projects by adding
>>>>>> in relative-path
>>>>>>
>>>>>>
>>>>>> Task
>>>>>>
>>>>>> * [UIMA-1755 <https://issues.apache.org/jira/browse/UIMA-1755>] -
>>>>>> Improve Maven build
>>>>>> * [UIMA-1816 <https://issues.apache.org/jira/browse/UIMA-1816>] -
>>>>>> update parent-pom-top references to version 2
>>>>>>
>>>>>>
>>>>>>
>>>>>> The release is staged here:
>>>>>> https://repository.apache.org/content/repositories/orgapacheuima-010/
>>>>>> 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-010/
>>>>>> </url>
>>>>>> </repository>
>>>>>> </repositories>
>>>>>> </profile>
>>>>>>
>>>>>> Please verify this by changing references to 1-SNAPSHOT versions of the
>>>>>> build artifacts (except the parent-pom-top which is at version 2, and
>>>>>> uima-docbook-olink project, which is not being released) to version 1
>>>>>> (without the SNAPSHOT), and see if things build, using the command
>>>>>>
>>>>>> mvn install -Pstaged-release
>>>>>>
>>>>>> More background on this approach is here:
>>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>>>
>>>>>> Also, please inspect the release artifacts to insure they have the
>>>>>> proper license /notice files.
>>>>>>
>>>>>> Vote open for 72 hours.
>>>>>>
>>>>>> [ ] +1
>>>>>> [ ] +0
>>>>>> [ ] -1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> +1
>>>>>
>>>>> Jörn
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: [VOTE] [POSSIBLE ISSUE] Release of build parent poms and tools,
version 1
Posted by Marshall Schor <ms...@schor.com>.
The parent-poms directory doesn't need to be there. I put it there,
just to "organize" all the parent poms under one directory, to keep
track of them :-).
The cause is, as usual, rooted in some discord between what is
programmed into Maven plugins as "conventions", and what the actual
directory layout is.
In this case, the plugin is the "assembly" plugin, and the feature I'm
using is the <moduleSets>, which picks of all of the sub modules and
gets their sources (obtained by whatever path the module elements
specify), and puts them all into a "flat" structure.
Another fix for this would be to figure out how to build a
source-release zip file that includes the modules, but is guaranteed to
be a (filtered) copy of the exact SVN layout. The filter would be
because only those projects listed in the <modules> section would be
included, along with any directories needed upto some (required) common
super directory of all the <modules>. I think this would require a
custom plugin, though.
-Marshall
On 6/26/2010 11:57 AM, Tommaso Teofili wrote:
> >From my point of view this is not blocking for the current release (so I am
> +1) but maybe it could make sense to abandon the parent-poms directory on
> SVN and have a cleaner structure, but I don't know if this parent-poms
> directory has to be there for some reason, maybe Marshall knows it better
> :-).
> Tommaso
>
> 2010/6/25 Marshall Schor <ms...@schor.com>
>
>
>> I did one more test, which was to get the "source-release" artifact
>> assembly and see if I could build the artifacts from it. For the
>> multi-module project "aggregate-parent-poms", the source-release
>> artifact is aggregate-parent-poms-1-source-release.zip.
>>
>> I unzipped that and found it generated a layout that's slightly
>> different from SVN. Because of this, the relative path to the <modules>
>> is missing the .../parent-poms/... directory, found in SVN. So, because
>> of this, doing mvn install on the aggregate-parent-poms project unzipped
>> here, fails.
>>
>> If you edit the <modules> section to remove the .../parent-poms/...
>> directory, mvn install works.
>>
>> So, the question is: is this a serious enough defect to warrant redoing
>> this release? I don't think so. Here are my reasons:
>>
>> 1) The aggregate-parent-poms project is there for 2 reasons:
>> a) to make building (and releasing) a bunch of the build artifacts in
>> one go, possible, and
>> b) to climb the learning curve on creating multi-module releases using
>> the release plugin
>>
>> 2) After this release, I suspect we will not be releasing all of these
>> at once, very often, but rather, just change those that need changing,
>> individually.
>>
>> If we were to redo this, I would abandon the parent-poms directory in
>> SVN, going back to the more "vanilla" directory structure, which would
>> match what the assembly descriptor makes for multi-module projects.
>>
>> So I'm a +1 for the release, but if others think we should fix this
>> before proceeding, I'll be happy to be over-ruled.
>>
>> Please express your opinion(s) :-)
>>
>> -Marshall
>>
>>
>>
>> On 6/25/2010 10:55 AM, Tommaso Teofili wrote:
>>
>>> +1
>>> Tommaso
>>>
>>> 2010/6/25 Jörn Kottmann <ko...@gmail.com>
>>>
>>>
>>>
>>>> Marshall Schor wrote:
>>>>
>>>>
>>>>
>>>>> The way we use Maven has been realigned to conform with more
>>>>> conventional ways of using Maven and best practices. This includes
>>>>> using the common Apache Release parent POM, the maven release plugin, a
>>>>> maven plugin for running the docbook processing, and many other
>>>>> improvements.
>>>>>
>>>>> The top parent pom for uima projects is already released (at version
>>>>> 2). This release is for the remaining build tools and parent poms, and
>>>>> is at version 1.
>>>>>
>>>>> Jira's fixed:
>>>>>
>>>>>
>>>>> Sub-task
>>>>>
>>>>> * [UIMA-1757 <https://issues.apache.org/jira/browse/UIMA-1757>] -
>>>>> use docbkx to create docbooks in place of current docbook tools
>>>>> project
>>>>> * [UIMA-1758 <https://issues.apache.org/jira/browse/UIMA-1758>] -
>>>>> remove dependency on checked-out other projects
>>>>> * [UIMA-1759 <https://issues.apache.org/jira/browse/UIMA-1759>] -
>>>>> make project versioning more conventional
>>>>> * [UIMA-1763 <https://issues.apache.org/jira/browse/UIMA-1763>] -
>>>>> Switch to using Nexus for releasing
>>>>>
>>>>>
>>>>> Bug
>>>>>
>>>>> * [UIMA-1051 <https://issues.apache.org/jira/browse/UIMA-1051>] -
>>>>> doc build not working on Linux
>>>>> * [UIMA-1805 <https://issues.apache.org/jira/browse/UIMA-1805>] -
>>>>> change aggregate for build projects version to follow version
>>>>> convention for those
>>>>> * [UIMA-1806 <https://issues.apache.org/jira/browse/UIMA-1806>] -
>>>>> fixes for releasing, in build poms
>>>>> * [UIMA-1813 <https://issues.apache.org/jira/browse/UIMA-1813>] -
>>>>> aggregate parent pom build fails rat test
>>>>>
>>>>>
>>>>> Improvement
>>>>>
>>>>> * [UIMA-1814 <https://issues.apache.org/jira/browse/UIMA-1814>] -
>>>>> Try making release:prepare work with all build projects by adding
>>>>> in relative-path
>>>>>
>>>>>
>>>>> Task
>>>>>
>>>>> * [UIMA-1755 <https://issues.apache.org/jira/browse/UIMA-1755>] -
>>>>> Improve Maven build
>>>>> * [UIMA-1816 <https://issues.apache.org/jira/browse/UIMA-1816>] -
>>>>> update parent-pom-top references to version 2
>>>>>
>>>>>
>>>>>
>>>>> The release is staged here:
>>>>> https://repository.apache.org/content/repositories/orgapacheuima-010/
>>>>> 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-010/
>>>>> </url>
>>>>> </repository>
>>>>> </repositories>
>>>>> </profile>
>>>>>
>>>>> Please verify this by changing references to 1-SNAPSHOT versions of the
>>>>> build artifacts (except the parent-pom-top which is at version 2, and
>>>>> uima-docbook-olink project, which is not being released) to version 1
>>>>> (without the SNAPSHOT), and see if things build, using the command
>>>>>
>>>>> mvn install -Pstaged-release
>>>>>
>>>>> More background on this approach is here:
>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>>
>>>>> Also, please inspect the release artifacts to insure they have the
>>>>> proper license /notice files.
>>>>>
>>>>> Vote open for 72 hours.
>>>>>
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> +1
>>>>
>>>> Jörn
>>>>
>>>>
>>>>
>>>
>>
>