rtc and multimodule maven projects - best practices
3 answers
I wrote the maven jazz scm provider. I work extensively with nested projects, eclipse and RTC. I'm still using RTC 3.0 as my working reference - that is what I developed and tested the plugin against.
My advise is NOT to flatten the structure, and keep the functionality that allows you to keep the release plugin, which IMHO, is the killer app feature of maven.
I've done some videos about this, I'll see if I can dig them up.
Eclispe does not have any issues with nested structure, not since 3.5, which it understands the concepts of Linked Projects.
RTC (at least V3), does not play as gracefully, but it does work. The odd thing about the Eclipse/RTC integration is that the RTC provider does not recognise the linked projects as being under source control. So you end up with the odd situation of making changes in one project, but can only check them in from the root project.
As for sharing, or having eclipse automatically find the nested projects (to make them linked), yes, as of at least V3, that did not work, so that has to be done manually. Doable, but painful.
Team Project Set Files (psf's) would have been good here, but they too are not supported under eclipse :-( At least not as of V3.
I've found a V4 VM that should be all nicely set up, so I'll see how that goes once I've finished downloading it.
I imported my proejcts from SVN, (in their fully nested structure), I disassociated the project from SVN, and then I shared the project into RTC. That is all that I needed to do.
If you want more details, then I can provide them.
-Chris
Comments
Chris, please, can you dig up the video? As this comes up repeatedly, I would also like to suggest to create an article around it.
Yes, that was something that I've always been meaning to do. The article and add some polish to the presentations. Let me find them.
-Chris
Chris,
The Ralph's suggestion is very interesting for me.
A question. Based on your recommendation, is it possible to put the projects of a multimodule project on different component?
For example, can I put the parent project into "Component A" and children projects on "Component B"?
Thanks in advance.
Bye.
I've seen it done, and it's lazy bad practice, and as we are talking best practices here...
I've seen it done where someone wanted a parent or a corporate pom (one that has the company wide settings in it) as the parent in a multi module project. This is lazy and bad practice. It also, in a Jazz SCM sense, makes no sense.
The correct way to manage it is to release (and manage) the parent (eg corporate) pom as a component in it's own right. This promotes reuse, which is a good thing.
Then, your project, "Component B" in your example, simply has it's root pom use "Component A", the corporate pom as it's parent.
Re "Is is possible to put the projects of a multimodule project (each) on different component(s)"?
No, and it makes no sense. Not in a maven sense.
By definition, the project (root and child projects) is the the component.
In SVN for example, the root pom would live in the trunk folder (or a branch), con convention. Your child projects are subdirectories off of the trunk or branch.
That is where a tag is made from; that is your definition of a component.
To further explain.
Historically, a lots of the maven SCM terms, thinking and consequently execution were derived from what they (and most of the world) used at the time, namely CVS/SVN etc.
The release plugin, is what manages the automatic version increments, tagging, checkin/checkout of the code. It provides a repeatable process for producing release code. Approximately 10% of the commits to the Apache SVN repo (1M+ commits) have been done by the maven release plugin.
Maven is a COC tool (Convention over Configuration), so my advise is to work with the tool, not against it.
By convention, a maven project, be it a single or multi module project has a root pom.xml, the root one is the one that has the <scm> section in it, along with others sections that only exist and make sense in the root pom.xml.
This is the section that lives in the trunk (or branch) in svn.
In SVN terms, a tag is a symbolic name for a path and a revision. The path is of the trunk (or branch, yes, you can run a release directly from a branch). So basically, the tag refers to everything under the tag or branch.
So the tag only basically refers to only that project. Making a tag across mutiple trunks (the svn equivalent of your multiple Components) makes no sense in maven terms and is not supported.
So, in SVN terms, you would see something like this:
http://some.host/svn/repo/some/path/to/your/project/trunk/...
Normally, the artifactId of the root pom.xml is the name of the project.
It is also very common to find the project name in the path as well, though it is not a requirement in SVN, I feel strong that it adds clarity as to what is going on.
eg, from the video samples I mentioned, you will see:
http://svn.warpspeed.com.au/svn/repos/GPDB/trunk/...
The GPDB project lives in the GPDB/trunk folder.
In Jazz SCM terms, what I do, is I map the project name to a Component, in this case, I create a GPDB Component from all of projects contained in the .../GPDB/trunk dir.
In maven Jazz SCM terms, the tag scm command is a "scm create snapshot" command, and this makes a snapshot of all components within the repository workspace.
This is why I recommend only ever running the maven release plugin in a repository workspace that only ever contains one component; the one that you want to release.
Yes, you could have other components in there as well, but they will also be tagged as well as a part of the snapshot. This is most probably not what you want.
The version numbers of the other components will also not be changed.
Sure, by all means develop in a repository workspace and sandbox with multiple components (you will need too), but don't ever run the release plugin in there. In maven terms, the end results make no sense.
As I originally said, maven is a COC tool. Work with it, not against it.
So, don't mix your components. Manage them separately and correctly, and you will not go wrong.
-Chris
Hi Chris,
we are trying to import SVN Maven Projects to RTC 4.0.6 and are struggling a bit. You have written several great forum dialogs. You reference links and videos to follow I was unable to find those. We are in need of some assistance and advise. Would you be available to discuss our roadblocks and suggest some solutions?
thanks in advance
Email me at ChrisGWarp@gmail.com
Ta
-Chris
much appreciated email on the way.
The problem with hierarchy is that RTC (as well as Eclipse) has problems with nested Eclipse projects. And Eclipse only shows and allows to edit Projects. RTC Follows the base Eclipse SCM paradigm and loads the folder as projects into RTC. If you have a hierarchy, RTC will find the top level .project file and load that folder. All contained Eclipse projects are ignored.
To handle the hierarchy you would have to make SCM to ignore the top level project. This is doable during the share. Then you have to load the full structure with a special load (create project for the folder), but then you can not load the nested projects.
You might be able to use load rules to load differently, but it is probably complex.
