Here's a wild guess as to what went wrong: I had previously tried doing release:prepare (using version 2.0-beta-9 of the release plugin which didn't have "flat" support). That had created the tag in SVN:
.../build/tags/aggregate-parent-poms-1 When I now re-ran the release:prepare, it did a svn copy from .../trunk to ..../build/tags/aggregate-parent-poms-1 I'm guessing that IF the target directory doesn't exist, then it is created and the elements under trunk are copied there. But if the target directory already exists, then the trunk directory is copied underneath that target directory. So, to make this work correctly, I first have to remove the aggregate-parent-poms-1 directory from the build/tags, I think. Perhaps the release plugin could check and complain (fail) if the target directory for this (and maybe other steps) already exists? -Marshall On 6/23/2010 2:26 PM, Marshall Schor wrote: > I looked at the poms in the SVN Tag, and they were re-written as > expected by the release-prepare, > but without the extra "trunk" directory. For example: > > <scm> > <connection> > > scm:svn:http://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms > </connection> > <developerConnection> > > scm:svn:https://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms > </developerConnection> > <url> > > http://svn.apache.org/viewvc/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms > </url> > </scm> > > So it looks like that part worked consistently with how the > release:perform expected (with no extra "trunk" directory. > > -Marshall > > On 6/23/2010 10:36 AM, Marshall Schor wrote: > >> forgot to add: I'm using maven version 3.0-beta-1 >> >> -Marshall >> >> On 6/23/2010 10:31 AM, Marshall Schor wrote: >> >> >>> I'm trying to do our first release using version 2.0 of the maven >>> release plugin for a multi-module project at Apache, with a flat >>> hierarchy. After failing because the Apache common pom was specifying >>> version 2.0-beta-9 of the release plugin (which didn't have the flat >>> hierarchy support), and redoing our top-level project pom to specify >>> release 2.0, I did the release-prepare on this structure: >>> >>> SVN: >>> build/trunk/aggregate-parent-poms >>> build/trunk/parent-pom-1 >>> build/trunk/parent-pom-2 >>> etc. >>> >>> where the "aggregate-parent-poms" project is one which uses >>> <modules><module>../parent-pom-1</module>... etc. to aggregate the other >>> projects. >>> >>> WORKING DIR where things are checked out: >>> build-trunk-data/aggregate-parent-poms >>> build-trunk-data/parent-pom-1 >>> build-trunk-data/parent-pom-2 >>> etc. >>> >>> mvn release:prepare worked, but it generated in SVN the structure: >>> >>> build/tags/aggregate-parent-poms-1/trunk/aggregate-parent-poms >>> build/tags/aggregate-parent-poms-1/trunk/parent-pom-1 >>> build/tags/aggregate-parent-poms-1/trunk/parent-pom-2 >>> etc. >>> >>> In reading the first comment for the flat-hierarchy support Jira issue >>> http://jira.codehaus.org/browse/MRELEASE-261 I noticed it says the fix >>> was to determine the directory in the maven module hierarchy which is >>> the common owning directory for all the projects with the hierarchy. In >>> this case, in the SVN hierarchy, it is "trunk". >>> >>> So I'm not sure if the SVN structure, with the "extra" "trunk" directory >>> is intentional or not. >>> >>> However, running, subsequently, the mvn release:perform goal, checked >>> out the SVN tag in to the aggregate-parent-poms/target/checkout with the >>> "trunk" directory included: >>> >>> WORKING DIR where things are checked out: >>> >>> build-trunk-data/aggregate-parent-poms/target/checkout/trunk/aggregate-parent-poms >>> build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-1 >>> build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-2 >>> etc. >>> >>> The next step, building the checked-out projects, failed, because it >>> didn't use that extra "trunk" directory, but instead tried to build the >>> aggregate from target/checkout/aggregate-parent-poms. The failure says: >>> >>> >>> build-trunk-data\aggregate-parent-poms\target\checkout\aggregate-parent-poms" >>> does not exist! >>> >>> which is, of course, true, because there's that extra "trunk" directory >>> in the path as checked out. >>> >>> So the build step apparently doesn't expect the extra trunk directory. >>> >>> A side note: each project has its own scm elements specifying where in >>> SVN it resides; these were correctly updated by the release:prepare. >>> This approach (having each project define its own scm elements) seems to >>> be required by "flat" hierarchy projects. >>> >>> Is this a known issue, and if so, is there a work-around? >>> >>> -Marshall >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
