directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [mina] changing groupId
Date Tue, 22 Mar 2005 07:20:04 GMT
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?


View raw message