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]
