[#SCM-342] scm:tag should support flat project layout

Maven SCM

scm:tag should support flat project layout

Created: 11/Sep/07 05:46 AM Updated: 10/Oct/08 10:19 AM

Component/s:

maven-plugin

Affects Version/s:

1.0

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:	1. flatProjectTagPatch.txt (6 kB)
Environment:	Windows XP, Eclipse 3.3

Complexity:

Intermediate

Description

« Hide

I have a Maven2 Flat Project Layout as described here: http://maven.apache.org/guides/mini/guide-ide-eclipse.html

Basically my directory layout is as follows:

/MavenRoot/pom.xml (this is the SuperPom)
/Module1/pom.xml
/Module2/pom.xml
/Module3/pom.xml

Modules 1,2 and 3 are specified in the <modules> section of the SuperPom (e.g() <module>../Module1</module>). Each POM contains its own CVS connection URL.

When I execute the scm:tag goal on the SuperPom in the MavenRoot project, only the MavenRoot project gets tagged. The same behaviour can be seen with the scm:update goal, which was fixed by providing a scm:update-subprojects goal.

I would like to see this behaviour fixed in the SCM plugin, while Maven2 advices a Flat Project Layout when working with Eclipse. At this moment I can't use the tag goal at all (it should be executed automatically by CruiseControl on a succesfull build).

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Duncan Doyle added a comment - 12/Sep/07 04:14 AM

I'm currently developing a fix for this issue, however I need some more info about other SCM tools. I'm familiar with how CVS tagging works, but I need to know whether other SCM tools (SubVersion, ClearCase, etc.) have the same behaviour in order for my algorithm to work.

So my question is if all SCM tools tag recursively (e.g. like CVS, tag the basedir all files in the directory tree which are under CVS control get tagged)?

The algorithm I have in mind works like this.

Keep a static HashSet in the class which contains processed (tagged) base directories of the ScmFileSets.
When a project executes a tag, check whether the basedir of its ScmFileSet is in the set of already processed basedirs. If it is present in the list, don't execute the tagging for this project. Otherwise continue.
Check whether the basedir of the project's ScmFileSet is a subdirectory of an already processed basedir in the static HashSet. If it is a subdirectory, skip the tagging because it has already been tagged recursively by another project. Otherwise, continue.
Execute the tagging on the project and add the ScmFileSet's basedir to the static HashSet.

Using this algorithm, the aggregator tag can be removed. If all SCM tools work like this, this algorithm will ensure correct tagging behaviour for boh standard - and flat project layouts.

[ Permlink | « Hide ]

Emmanuel Venisse added a comment - 12/Sep/07 08:26 AM

Normally, all SCM tools tag recursively but it won't work in some case.

With subversion (it can be the same for cvs and others), some users use a flat layout on their own machine but not in the SCM. for exemple with svn:

in svn:

  ROOT/
      module1/
            branches/
            tags/
            trunk/
                pom.xml
      module2/
            branches/
            tags/
            trunk/
                pom.xml

and in working copy:

  ROOT/
      module1/
                pom.xml
      module2/
                pom.xml

With this structure, some users will want a global tag under ROOT/tags/ and some others will want one tag by module under /ROOT/moduleX/tags/

[ Permlink | « Hide ]

Duncan Doyle added a comment - 13/Sep/07 04:11 AM

So, how would one solve that with the current way that the scm:tag works??

Basically in the case you outlined, one needs to issue 2 mvn scm:tag commands, if neither pom is a superpom of the other. In that case, my algorithm would still work.

What is your opinion on how to solve this issue? Basically the main usage (for me that is) of the scm:tag command is to automatically tag a complete project using a single command in a nightly build process (e.g. CruiseControl, Continuum) using the build number as tag. And the single command should work for both a 'normal' maven layout as well as a flat project layout.

[ Permlink | « Hide ]

Emmanuel Venisse added a comment - 13/Sep/07 04:37 AM

if relative path defined in module exists in SCM, your algorithm should work.

About nightly builds, I think it should be the job of the CI tool to create a tag if the build is ok. This feature will be implemented in a future Continuum version

[ Permlink | « Hide ]

Duncan Doyle added a comment - 13/Dec/07 06:08 PM - edited

I've attached a patch.

The patch provides support for tagging a flat project layout. I've disabled the @aggregator Maven option to process multiple modules. Furthermore. it basically keeps track of all the ScmFileSet basedirectories which have been processed in a static HashSet. Before a new fileset is tagged, it checks that the ScmFileSet has not already been processed. Next it checks that the current ScmFileSet is not a sub-directory of an already processed basedir. If that's all true, the fileset is tagged and its basedir is added to the static HashSet..

This solution works in both a standard Maven2 layout (i.e. not tagging sub-projects twice because it keeps track of already processed basedirs) and a flat layout (i.e. because the @aggregator option is disabled).

[ Permlink | « Hide ]

Vincent Siveton added a comment - 03/Sep/08 07:18 PM

I am not comfortable to remove the @aggregator.

[ Permlink | « Hide ]

Duncan Doyle added a comment - 09/Oct/08 05:23 PM

Vincent, why are you not comfortable to remove the @aggregator? The current tagging functionality basically doesn't work with any flat project layout. The patch supplied has been in production at our company for over a year without any issues. I would really like to see this issue closed one way or the other, it has been open for over a year now.

[ Permlink | « Hide ]

Duncan Doyle added a comment - 10/Oct/08 10:19 AM

OK, I did some testing today using my patch on a Subversion repo ...... and it fails. The problem seems to be that when I specify a connection URL like "scm:svn:svn://localhost/testrepo/trunk/MavenRoot" for the Super Pom project (see the example in my original post), the directory in which the files are put are "/testrepo/tags/{myTag}" and NOT "/testrepo/tags/{myTag}/MavenRoot". I had expected that the SCM plugin would generate the latter structure, but it doesn't.

This results in a situation in which the tagging of the second project fails. Its connection URL is "scm:svn:svn//localhost/testrepo/trunk/Module1", and when the tag goal executes (with the patched plugin) it wants to create this structure "/testrepo/tags/{myTag}", which has already been created by the MavenRoot project, so the tagging fails.

I did another test in which I put my modules in a RootFolder in Subversion, so the location is "testrepo/trunk/RootFolder". So this RootFolder contains all the modules. I also adjusted the connection URLs in my POMs. When trying to tag this project, the directory was again "/testrepo/tags/{myTag}" and did not preserve the folder structure in the trunk.

Why does the plugin not preserve the original folder structure when tagging a project? There seems to be some other issues open on the SCM Subversion which basically have to do with the same problem, the plugin not being able to support a flat project stucture.