I would like to change the groupId for mina. I'll explain why and how
this is going to lead to a general rule of thumb to follow for projects
with a trunk. I'm posting here because I don't know if this is
absolutely the right thing to do so please let me know.
Maven plugins for IDE's can associate projects that depend on one
another in 2 ways:
(1) a dependency on a jar in the local repo
(2) a dependency on another project within the IDE rather than a built jar
If all deps are within the same groupId then the plugins generate a
project descriptor that has deps on another IDE project rather than a
built jar. If the dep is to an artifact within another groupId then the
dep is to a built jar.
We have been following a convention where all the projects within a
trunk have the same groupId. I don't know if this is the right way to
go - or a convention that should be followed. If there is a dep
artifact that is in the same groupId but not within the trunk then these
plugins do not include the dep. For example in apacheds/trunk the main
has a dep on MINA which is in the 'directory' groupId. When I generate
an idea multi-project in apacheds/trunk the project is missing the MINA
dep. I have to add it manually. If MINA were in its own groupId then
we would not have this problem. So we could just change MINA's groupId
to say 'directory-network'. This way the generated project shows the
built MINA jar as the dep.
Now we could set a general rule where every trunk has its own groupId.
If we do this though we run into a problem with the 'shared' area which
does not fit into this convention. The problem here is that shared
contains multiple trunks like ldap/trunk and kerberos/trunk however
these all have the same groupId because there is a POM right inside
'shared' that is extended by a POM in each trunk. This is probably a
bad move in general because we're referencing a file outside of the unit
of branchable, taggable code (a trunk) in svn. Further more its bad
if/when we start introducing deps across trunks in 'shared' which now
creates the same issues with the IDE project generation mentioned above.
Anyone have comments on how to resolve these problems?
Alex
|