rtc and multimodule maven projects - best practices

Angelo Corna (263●5●83●83) | asked Nov 27 '13, 4:02 a.m.
retagged Dec 16 '13, 11:57 a.m. by David Lafreniere (4.8k●7)

We need to manage multimodule Maven project on RTC and searching some information on this topic we've found an interesting post (http://phkrief.wordpress.com/2010/09/24/when-maven-meets-rational-team-concert/) with some considerations regarding this issue and the suggestion here is to flatten the Maven structure.

I've found another post on jazz.net (https://jazz.net/forum/questions/35231/maven-multi-module-projects-in-eclipse) with this information

Some people recommend creating a flat Maven project structure, where the parent and child projects are at the same level in the file system, and the parent POM refers to the child projects using e.g. "../child". But that has some limitations, e.g. the Maven release plugin does not understand this flat structure.

What are the best practices and the attention points for this issue and more in general for the Maven projects management in RTC?

3 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Chris Graham (367●9●14) | answered Nov 27 '13, 7:38 p.m.

Hello All.

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

Ralph Schoon commented Nov 28 '13, 2:18 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Chris Graham commented Nov 28 '13, 6:31 a.m.

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

Angelo Corna commented Nov 29 '13, 10:53 a.m. | edited Nov 30 '13, 11:23 a.m.

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.

Chris Graham commented Nov 29 '13, 7:54 p.m.

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.

Chris Graham commented Nov 29 '13, 8:25 p.m.

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.

Chris Graham commented Nov 29 '13, 8:37 p.m.

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.

Chris Graham commented Nov 29 '13, 8:43 p.m.

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

Wendy Murphy commented Mar 19 '14, 4:29 p.m.

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

Chris Graham commented Mar 19 '14, 9:08 p.m.

Email me at ChrisGWarp@gmail.com
Ta
-Chris

Wendy Murphy commented Mar 21 '14, 8:50 a.m.

much appreciated email on the way.

showing 5 of 10 show 5 more comments

permanent link

Ralph Schoon (63.5k●3●36●46) | answered Nov 27 '13, 5:18 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

See: http://phkrief.wordpress.com/tag/maven/ and follow the advice to make it flat.

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.

Comments

Philippe Krief commented Nov 27 '13, 9:55 a.m. | edited Nov 30 '13, 11:22 a.m.

JAZZ DEVELOPER

So, Angelo, it seems that my post is still up-to-date based on Ralph's answer.
Thanks Ralph !

Angelo Corna commented Nov 27 '13, 5:20 p.m. | edited Nov 30 '13, 11:22 a.m.

Ralph, Philippe,

thanks for your response.

Do you have any comments regarding the limitations mentioned on post 35231?

Thanks in advance.
Bye.

0	permanent link Rafael Pirolla (16●4●9) \| answered Dec 19 '14, 1:33 p.m. Hello, Is this still up-to-date information? Kind regards, Pirolla.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

It's all about the answers!

Related questions

rtc and multimodule maven projects - best practices

3 answers

Your answer