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 <[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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
