|
Hi John.
Thanks for the update. Also, we have scenarios where you may have: Parent (under cvs:/group/module1)
Will that work in this scenario? Well in that case the common directory is '/' which is probably not what you want as all other folders under '/' would be operated on (checked-in, tagged, etc). Our assumption has been that there is some unifying directory that represented the logical base for the modules underneath it.
We have a similar setup in regards to your master corporate pom project, that can, via a profile, include all our other projects. i.e. /corporate-pom/pom.xml project-a and project-b, etc all have corporate-pom as their parent and, as i've said, corporate-pom can build all the projects (a,b, etc) (via a profile that include <modules><module>../project-a</module> etc </modules>) but one would not want to release the corporate-pom AND all these other projects at the same time. The 'all projects' setting on the corporate-pom is just for building a master site. In our setup one releases corporate-pom, project-a , project-b etc separately as they represent completing different projects with their own release cycles etc. Re when will it be avilable? Well we've done the analysis but I'm off for 2 days now so I expect we won't get patches submitted until next week. Great Stuff Guys
I am not in the office to create a release till the end of the month. I have to say I am having problems with many plugins as a result of using the flat file structure (site plugin for one). This is great news for me as it will save me a lot of time as you can imagine if a project has lots of modules it can become a real pain to do things by hand. Thanks for your hard work. Hi Paul, we have no problems with the site plugin (bar multiple parents being included in the parent menu, see the recently updated MSITE issues) but that is using a site plugin that we've built ourself with a number of patches applied. Specifically though it works for 'flat multimodule' structures.
Hi John,
Any news on the patch? I have browsed the repository, but it doesn't look like any fixes has been applied regarding this issue. I got an email from John Allen that signified his team did not make significant progress on modifying the plugin, and has since abandoned the research, using, instead, a plugin to modify eclipse imports.
I'm looking at the solution he found – http://eclipse-tools.sourceforge.net/projecttransfer/usage.html Paul, have you been able to make any progress? Nope Sorry I got no where I just put up with the pain.
Paul Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from the dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc)
Hi all,
making assumption about directory structure and the fact there is a common ancestor is wrong too! I have this svn structure
and the developper desktop structure based on that svn: {pre}/home/user/dev/project/topModule (=http://server/project/topModule/trunk/ I expect release plugin to read the submodules pom files, and especially the <scm> entries in that poms, that clearly indicate the svn path of each submodule, which should be tagged as this (using 1.1.1 as release version):
currently, only the first tag is generated, not the submodules tags. The idea is that, during release, if plugin encounter a submodule which as a <scm> which is different than that of parent, it should also tag it. Attaching a prospective workaround patch for this issue.
Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo. Then in your relative parent pom you can configure like this: <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-7-PATCHED</version>
<configuration>
<tagWorkingDirectory>${basedir}/..</tagWorkingDirectory>
<preparationGoals>
clean verify -f ${artifactId}/pom.xml
</preparationGoals>
<connectionUrl>scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}</connectionUrl>
<goals>clean deploy</goals>
<pomFileName>${artifactId}/pom.xml</pomFileName>
<arguments>-f ${artifactId}/pom.xml</arguments>
</configuration>
</plugin>
The additional config is to ensure the parent pom gets found for the forked lifecycles in release:prepare and release:perform. In addition, due to the release manager now putting the release descriptor (release.properties) in $[basedir}/.. you need to specify the connectionUrl for release:perform. I guess you could write some script to move it or, as above, fill in the url apart from the release version e.g. #hello-world/hello-world-parent> mvn release:prepare release:perform -Drelease.version=1.7 --batch-mode Hope this is useful. Adam does the 2.0-beta-8-SNAPSHOT version already includes this fix? If not how can i use the patched version?
I tried apply your workaround to the 2.0-beta-8-SNAPSHOT but got the following error: [INFO] ---------------------------------------------------------------------------- Tnx
Here's what we did for a workaround:
In the example above, I would have created a POM.XML in the D:\TEMP\MYSTUFF directory with one sub module, ROOT\POM.XML. No projects refer to it as a parent. It is only a way to identify which sub-module is the "real" root. When doing our development in eclipse, we don't have that new POM.XML available. It only shows up when we checkout the whole project. We then run the Manven release:branch and release:prepare mojos from that directory, and everything seems to work fine. Example: proj\+pom.xml (sub module: base)
|
|--base
| |+pom.xml (sub modules: ../client, ../server)
|
|--client
| |+pom.xml (parent: ../base)
|
|--server
|+pom.xml (parent: ../base)
All maven release stuff is done from the proj directory, but all of the eclipse projects are at their specific project level. If a fix is done for this, I would love to help out with the testing. We have a relatively complicated configuration (3 levels of hierarchy) that I could test against. Yes it's work fine, In our case, the "root" pom is a child of the "parent" in order to benefit the release change version system and retrieving SCM information. The only bad news is that the generated site mention the "root" module as a real separated module. Any news on this. Not being able to release a flat structure is a real PITA - and having nearly empty pom.xml's around just to satisfy maven is really bad publicity...
We also using a "flat" hierarchy for some of our projects.
Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch. We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or may be branched). All projects are tagged under a common directory and "release:perform" also do the job for us. I've you are brave, you could give "flatProject.main.patch" a try. (We also assume that the layout of the working copy matches the layout in a single repository.) Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974) I see there are several patches attached to this issue.
What's the current status? Have any of patches been reviewed/tested? Is there something else that non-committers can provide to help in fixing the issue? I'm currently working on fixing flat multi-module issues with Continuum and I'd probably be touching this issue since Continuum and the maven-release-plugin use the same release manager component. I'll take a look at the attached patches when I get to fixing the releasing part of flat multi-modules.
See comments in CONTINUUM-1569 for details on how we're approaching this in Continuum.. A workaround that I have used successfully in the past has been:
1. Organize the modules and parent in a flat pattern with <module>../module1</module> etc. in the parent. Eclipse can ignore the aggregator as it is not referenced by any pom. Attaching
The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin. I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance.. Any chance you create an it test for that ?
I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module.
Attaching revised patch with integration tests for a flat multi-module project and a regular multi-module project.
I can't find particular issue (only tested with svn) .
So +1 to commit this. Attached patch with a couple of fixes for the tag url written in the pom and additional tests.
If no one objects to the fix I did, I'll commit it to trunk already..
Fixed in trunk 778088 (applied
Additional fix for determining the common path which was failing in windows was committed to trunk -r778269.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
release:prepare shouls support flat directory multimodule projects
Currently the 'working directory' of the 'execution project' is assumed to be the top 'ancestor' directory for which all projects contained within the reactor will live under. This is obviously incorrect for flat based projects. The fix is simply a case of determining what the directory in the maven module hierarchy is the common owning directory for all the projects with the hierarchy (which for nested projects happens to be of course the same as the execution project's home, or in other words the working directory').
For instance (please excuse ASCII art)
These two are logically equivalent.
The observation is that tagging, branching, checkout, checkin etc are version controlled based operations and the majority of VCS systems provide a file system based model (not bothering with object based VC systems here).
So when we want to tag the stuff in MYSTUFF/TRUNK what we really want to do is create something under the TAGS in SVN (say) that has the trunk contents, thus:
By going through the module hierarchy and finding the common directory ancestor we are able to perform all the correct SVN operations (CO, CI, TAG, ETC).
i.e. For the nested structure the common ancestor directory IS the current directory:
Top common ancestor directory is equal to 'D:\TEMP\MYSTUFF' which happens to be the same as the working directory of the execution project (the top POM.XML).
The same approach (of working out the common ancestor) works the on a flat structure but identifies that D:\TEMP\MYSTUFF is the common directory and NOT the execution projects' working directory which is in fact D:\TEMP\MYSTUFF\ROOT\
Cool. So now the only problem is in handling the perform operations where the plugin needs no project, simply checks out everything from the tag URL. Checkout works just fine but there is one critical piece of information missing, namely the path into the 'ROOT' project so that the build can start. This extra bit of information is simply added to the ReleaseConfiguration (that is persisted as release.properties). The perform reads this is an makes that the 'working directory' before it calls maven executor and then kicks off the build.
Note: Maven is full of assumptions regarding the location of modules being 'beneath' the parent project, for instance the default scheme for constructing URLs and SCM URLS has the derived projects taking the parent's URL and tacking its artifactId on the end. For all us flat-project guys you can usually work around these issues through explicit definition of the elements in the child/derived projects.