You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2010/06/23 16:31:05 UTC
using Release plugin version 2.0 doing flat hierarchy release - problem
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
Re: using Release plugin version 2.0 doing flat hierarchy release
- problem
Posted by Marshall Schor <ms...@schor.com>.
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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release
- problem
Posted by Marshall Schor <ms...@schor.com>.
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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release
- problem
Posted by Marshall Schor <ms...@schor.com>.
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release
- problem
Posted by Marshall Schor <ms...@schor.com>.
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
>
>
>