You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by jo...@capgemini-sdm.com on 2009/08/27 22:39:57 UTC
MRELEASE-261 - Fix for Maven2 Release Plugin concerning flat multi-project structures does not work for us
Hello everyone,
we have a problem with the Release Plugin due to our flat multi-project
structure in both the developer's hard drive and the CVS repository.
The bug is described in http://jira.codehaus.org/browse/MRELEASE-225 <http://jira.codehaus.org/browse/MRELEASE-225> ,
which is marked as duplicate of http://jira.codehaus.org/browse/MRELEASE-261 <http://jira.codehaus.org/browse/MRELEASE-261>
although I think they describe slightly different problems.
I write this email because the bug #261 is closed and I am not sure that a
comment on a closed bug will draw any attention.
As you can see in 261, the committer Maria Odea Ching added some patches.
Sadly they don't work for us, because they might solve the flat-structure
on hard drive problem, but not the flat-structure in repository. At least I didn't
get it working :-/
We wrote a patch based on the last patch version of Maria Odea Ching (trunk -r778269),
that works for us and does not break the provided unit tests. You can find the patch
as an attachment.
We need a fast solution because at the moment we use our self-built release plugin
which seems to depend on many snapshot versions of other plugins which might change
without notice.
Our concrete situation is the following:
We use CVS. We have a flat structure on the disk (eclipse workspace) like
eclipse-workspace-else\anything-parent
eclipse-workspace-else\anything-module1
eclipse-workspace-else\anything-module2
and in the CVS repository we have the same flat hierarchy
anything-else\anything-parent
anything-else\anything-module1
anything-else\anything-module2
The first error was the rootProjectPath, which is calculated as the common
ending part of both the POM's scm connection and project's working directory.
eclipse-workspace-else\anything-parent
anything-else\anything-parent
lead to
-else\anything-parent
The command
mvn release:prepare
only works with the additional argument
-DcommitByProject=true
although we created a new folder and checked out the projects with their parent
folder ("anything-else"). But that might be another issue.
When we tried to invoke
mvn release:perform
it didn't work because the cvs command only checked out the module anything-else\anything-parent
- that is not enough - but tried to build ALL artifacts. This seems to happen because the plugin thinks
that at least the CVS repository has a hierarchical structure.
So we changed the command to
mvn release:perform -DworkingDirectory=.\target\checkout\anything-else -DscmConnection=...host:port:repository:anything-else
The checkout worked well, but then another problem came up:
The rootProjectPath (the match from POMs scm connection and project's working directory; anything-else\anything-parent in this case)
was added to the working directory, so Maven tried to build in the directory ...\target\checkout\anything-else\anything-else\anything-parent.
Damn :-)
Now I try to explain our changes.
RollbackReleaseMojo
Added option commitByProject to match with the corresponding PrepareReleaseMojo option.
Otherwise I can't rollback the release, because the release-manager looks for anything-module1\pom.xml
under anything-parent.
ReleaseUtil
.getRootProjectPath(MavenProject)
Relates to the problem with
eclipse-workspace-else\anything-parent
anything-else\anything-parent
==> -else\anything-parent
So I changed it to split the strings into segments, using "/" as a separator. Only completely matching
segments are combined to the resulting common path. So something\root-project and anything\root-project
would result in root-project
.getCommonPath(String, String, String, boolean)
Therefore I needed an additional getCommonPath(...)-method that contains the previous behaviour
and the new one.
ReleaseUtilTest
.testGetRootProjectPathFlatStructureWithSegments()
.testGetRootProjectPathFlatStructureWithSegmentsAndSCMDelimiters()
Here are some additional tests for the changes.
AbstractRunGoalsPhase
.determineWorkingDirectory(File, String, String)
I changed the code to watch out if the end of the calculated working directory
matches the beginning of the rootProjectPath. So now, ...\target\checkout\anything-else
and \anything-else\anything-parent will be melted into ...\target\checkout\anything-else\anything-parent
Well, the code is not the best one, but it works. Some additional checks might be necessary,
because the code does not recognize something like ...\target\checkout\123-anything-else,
which must result in ...\target\checkout\123-anything-else\anything-else\anything-parent
(unless the rootProjectPath starts with a "/").
.execute(ReleaseDescriptor, ReleaseEnvironment, File, String)
The resulting working directory (...\target\checkout\anything-else\anything-parent) does not exist
and is not created, because the checkout directory is specified as ...\target\checkout (default; or in my case:
...\target\checkout\anything-else), so the build crashes. Now at least I try to create it. If an exception
occurs, well, that's bad luck :-)
We would appreciate to see these changes make it into the next release and the release coming soon :-)
Thanks for your time
Johannes
AW: MRELEASE-261 - Fix for Maven2 Release Plugin concerning flat multi-project structures does not work for us
Posted by jo...@capgemini-sdm.com.
Hello Barrie,
thanks for your time and your helpful suggestions.
Please see my comments below.
Johannes
> -----Ursprüngliche Nachricht-----
> Von: Barrie Treloar [mailto:baerrach@gmail.com]
> Gesendet: Freitag, 28. August 2009 02:00
> An: Maven Developers List
> Betreff: Re: MRELEASE-261 - Fix for Maven2 Release Plugin
> concerning flat multi-project structures does not work for us
>
> On Fri, Aug 28, 2009 at 6:09 AM,
> <jo...@capgemini-sdm.com> wrote:
> > Hello everyone,
> >
> > we have a problem with the Release Plugin due to our flat
> > multi-project structure in both the developer's hard drive
> and the CVS repository.
> > The bug is described in
> http://jira.codehaus.org/browse/MRELEASE-225,
> > which is marked as duplicate of
> > http://jira.codehaus.org/browse/MRELEASE-261
> > although I think they describe slightly different problems.
>
> It sounds likes you have a bunch of issues that aren't easily
> addressed.
I think it sounds worse than it is. :-)
>
> A non-maven workaround might be to manually release each project.
>
> Modules give you the "helper" ability to run a maven command
> at the top of a project and for the same command to be
> applied to all modules (recursively).
> But this doesn't affect the dependency declarations in anyway
> (they stay the same regardless of whether there are modules
> present or not)
We do use modules in our parent pom (anything-else\anything-parent\pom.xml)
<modules>
<module>..\anything-module1</module>
<module>..\anything-module2</module>
<module>..\anything-module3</module>
</modules>
>
> I'm assuming you have customized parent/relativePath in your
> poms to get the flat structure.
No, the child poms only contain
<parent>
<groupId>anything</groupId>
<artifactId>anything-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
> If maven can't find the parent then it will use the installed
> version instead.
> You will need to delete parent/relativePath to try this.
>
> So if you remove all modules (and parent/relativePath) and
> then manually invoke mvn release on each project in the same
> order that the module defintions would have you should have
> the correct behaviour.
Releasing one single project works. May I remind you, that the
the directory structure on the disk is not the problem. It's the
missing hierarchy in the CVS repository. The plugin seems not
to be able to handle this missing hierarchy.
If the disk was flat but the repository would look like
- anything-else
|
|- anything-parent
|- pom.xml
|- anything-module1
|- pom.xml
|- anything-module2
|- pom.xml
|- anything-module3
|- pom.xml
it would work, because with checking out anything-else\anything-parent
all the files would be on the disk.
But the directory structure looks like
- anything-else
|
|- anything-parent
| |- pom.xml
|- anything-module1
| |- pom.xml
|- anything-module2
| |- pom.xml
|- anything-module3
|- pom.xml
So the plugin checks out anything-else\anything-parent (and subfolders)
and does not realize, that this is not enough.
I think the calculation of the rootProjectPath might not be correct
(or I don't understand it :-) ) I would expect that the rootProjectPath
is the path segment common to all modules. For calculation I would
check the parent's and the module's directories so that my result of
a structure like
- anything-else
|
|- anything-parent
| |- pom.xml
|- anything-module1
| |- pom.xml
|- anything-module2
| |- pom.xml
|- anything-module3
|- pom.xml
would be "anything-else", which is common to all modules.
But the currently implemented solution is to find common segments of
the project's base director (f.i. C:\anything-else\anything-parent)
and the scm-connection (f.i. ...host:port:repository:anything-else\anything-parent)
That leads to a working directory like anything-else\anything-parent.
anything-else != anything-else\anything-parent
Any ideas?
>
> You should be able to see if this is a viable solution after
> the first couple of released projects.
> If it is viable you can then script the maven commands.
Well, with Maria Odea Ching's and our patches applied
the Maven2 Release Plugin invoked with the additional arguments
mvn release:prepare -DcommitByProject=true
and
mvn release:perform -DworkingDirectory=.\target\checkout\anything-else
-DscmConnection=...host:port:repository:anything-else
works for us.
The bottom line of our patch is:
- avoid incorrect rootProjectPath (compare whole segments only)
- create the rootProjectPath if it does not exist (because the
working directory is deleted within CheckoutProjectFromScm.execute(...))
- check if the end of the workingDirectory is the beginning of the
rootProjectPath and merge them if necessary.
These changes do not seem to be related to our particular scenario.
>
> Another alternative is to manually release the project.
> If release:prepare is working for you, then just checkout the
> tagged version and run mvn deploy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-261 - Fix for Maven2 Release Plugin concerning flat
multi-project structures does not work for us
Posted by Barrie Treloar <ba...@gmail.com>.
On Fri, Aug 28, 2009 at 6:09 AM,
<jo...@capgemini-sdm.com> wrote:
> Hello everyone,
>
> we have a problem with the Release Plugin due to our flat multi-project
> structure in both the developer's hard drive and the CVS repository.
> The bug is described in http://jira.codehaus.org/browse/MRELEASE-225,
> which is marked as duplicate of http://jira.codehaus.org/browse/MRELEASE-261
> although I think they describe slightly different problems.
It sounds likes you have a bunch of issues that aren't easily addressed.
A non-maven workaround might be to manually release each project.
Modules give you the "helper" ability to run a maven command at the
top of a project and for the same command to be applied to all modules
(recursively).
But this doesn't affect the dependency declarations in anyway (they
stay the same regardless of whether there are modules present or not)
I'm assuming you have customized parent/relativePath in your poms to
get the flat structure.
If maven can't find the parent then it will use the installed version instead.
You will need to delete parent/relativePath to try this.
So if you remove all modules (and parent/relativePath) and then
manually invoke mvn release on each project in the same order that the
module defintions would have you should have the correct behaviour.
You should be able to see if this is a viable solution after the first
couple of released projects.
If it is viable you can then script the maven commands.
Another alternative is to manually release the project.
If release:prepare is working for you, then just checkout the tagged
version and run mvn deploy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org