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
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
