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 <[email protected]> > > >> 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 <[email protected]> >>> >>> >>> >>>> 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 >>>> >>>> >>>> >>> >> >
