I think I can guess the reason for this behavior - the SVN target when creating the tag (e.g., ...build/tags/aggregate-parent-poms-1) must not already exist in SVN, otherwise the svn copy a/b/c/xxx ...build/tags/aggregate-parent-poms-1 puts "xxx" as a new directory under the existing build/tags/aggregate-parent-poms-1, rather than putting the children of "xxx" under the new dir build/tags/aggregate-parent-poms-1.
I'm manually fixing this now in SVN and will proceed with trying to get the build poms and tools released to the staging repo so we can vote on the whole lot :-) -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 > > >
