Should we use RTC SCM Components in a Multi-module Maven project?
Accepted answer
How many components you want to use is mainly determined by how you want to organize your resources. It may help with how you want to load your content or configure your streams. Components will help you divide the content into parts that can scope what you want to load.
What you will probably want to do is check if you ever want to load some of the modules and not all of them. You'll want to separate them in components that make it easy to load without loading unnecessary content.
If whatever you do isn't quite what you want and you don't realize it until later, you can perform a move in the repository. It will move a top level folder in your component into another component while preserving history.
One other answer
As the author of the Jazz Maven plugin, I can say most definately NOT!
The simple reason is in the history of the scm plugins and the release plugins. Historically, they came from cvs, then svn and then now, git.
with svn particularly, you create a single tag at a trunk or branch (and everything below it) for that release. This is how it's always been done.
From a Jazz perspective, it makes no sense to have a snapshot taken of multiple components, just the one that you're releasing.
From a build and release perspective, only a single checkout, or load in jazz terms is performed using the scm section in the root pom.xml, if you were to put a scm section in the nested modules, they are ignored.
You've got to remember, that maven uses the scm plugins (which are a very thin abstraction layer - again, historically based around cvs and svn) to do all scm operations and the release manager (inside the release plugin) uses the scm api, to perform all of it's work. Being an abstraction layer, you do not always get to use all of the really nice features of any particular VCS, just those that are abstracted, and in the manner that the abstraction layer wants. In short: It's a subset of the full features offered by (all but the simplest of) VCSs.
Maven is opinionated software, and this is one of those times where you are best off NOT fighting it, simply do it the way it wants and you'll have far less troubles.
In this case, I recommend using a nested structure, all within a single component, as that is the way that maven (pretty much forces) wants you to work.
Again, RTC etc, offers a superset of being able to construct eclipse workspaces etc with multiple components, and if you flatten them, you might even get a multi module build (as in mvn package) to work, but you will have issues getting the release plugin (remember, one single LOAD being called) to work. So you will need to work within the additional constraints of what the release plugin can do.
That is the way that I developed and tested the plugin. When we started, there was no command line option to create a baseline, only a snapshot, and that applies to a Component.
The most interesting parallel is that of git. where the best practices there are to have a repo per root pom, or in RTC terms, a component.
The simple reason is in the history of the scm plugins and the release plugins. Historically, they came from cvs, then svn and then now, git.
with svn particularly, you create a single tag at a trunk or branch (and everything below it) for that release. This is how it's always been done.
From a Jazz perspective, it makes no sense to have a snapshot taken of multiple components, just the one that you're releasing.
From a build and release perspective, only a single checkout, or load in jazz terms is performed using the scm section in the root pom.xml, if you were to put a scm section in the nested modules, they are ignored.
You've got to remember, that maven uses the scm plugins (which are a very thin abstraction layer - again, historically based around cvs and svn) to do all scm operations and the release manager (inside the release plugin) uses the scm api, to perform all of it's work. Being an abstraction layer, you do not always get to use all of the really nice features of any particular VCS, just those that are abstracted, and in the manner that the abstraction layer wants. In short: It's a subset of the full features offered by (all but the simplest of) VCSs.
Maven is opinionated software, and this is one of those times where you are best off NOT fighting it, simply do it the way it wants and you'll have far less troubles.
In this case, I recommend using a nested structure, all within a single component, as that is the way that maven (pretty much forces) wants you to work.
Again, RTC etc, offers a superset of being able to construct eclipse workspaces etc with multiple components, and if you flatten them, you might even get a multi module build (as in mvn package) to work, but you will have issues getting the release plugin (remember, one single LOAD being called) to work. So you will need to work within the additional constraints of what the release plugin can do.
That is the way that I developed and tested the plugin. When we started, there was no command line option to create a baseline, only a snapshot, and that applies to a Component.
The most interesting parallel is that of git. where the best practices there are to have a repo per root pom, or in RTC terms, a component.