[mina] changing groupId

[Alex Karasulu <ao...@bellsouth.net>]

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

Re: [mina] changing groupId

[Alex Karasulu <ao...@bellsouth.net>]

Hey thanks for taking a look at all this.  I will apply your 
recommendations and look for changes in the IDEA plugin.  If not I guess 
we can go into her and make it work.  Just don't have the strength for 
Jelly anymore :).

Alex

Brett Porter wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Alex,
>
>  
>
>>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.
>
>This is really a deficiency of the current plugin - it should only link
>other projects built within an idea:multiproject run (or eclipse
>equivalent), and deps for everything else, or at least follow a
>configuration item. Fixing the plugin may be a better alternative than
>working directory around it if that is the only issue.
>
>  
>
>>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.
>
>If group ID's are still changing, can I request that you mirror the
>package? ie org.apache.directory.naming, org.apache.directory.network,
>etc. Or just org.apache.directory if it is decided to share them.
>
>  
>
>>Now we could set a general rule where every trunk has its own groupId.
>>    
>>
>
>This seems a good rule in general, regardless of the current split.
>
>  
>
>>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.
>
>The only way to maintain a versionable parent POM here with Maven 1.x is
>to make a copy of the files when it changes (project-1.0.xml,
>project-1.0.1.xml), as it shouldn't happen too often. Alternatively,
>manually merge the POM in the tags directory after a release, or just
>merge them now and maintain separate copies.
>
>  
>
>>Anyone have comments on how to resolve these problems?
>>    
>>
>
>I'm not entirely certain the "shared" structure is right, or the number
>of trunks. The fact that everything is being versioned together
>indicates their development is really tied to each other - at least at
>this point. The only exceptions seem to be naming (separate from the
>start), mina and maybe asn1 (which has been branched a few times). In
>this instance, I'd expect to see a single trunk with the project
>hierarchy underneath it.
>
>The tree has been changing constantly over the past few months. I'd
>suggest sitting on it right now - the problems that exist with IDEs can
>be fixed, and the shared/project.xml is not really a big issue until it
>comes time to make a release. Learn what works and what doesn't, and
>approach it again later with a more wholistic view.
>
>- - Brett
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.0 (Cygwin)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCQVzsOb5RoQhMkRMRAq/jAKC0Otq49BhmGjqvxEgmZUrr3t4OwACgmRqk
>os3kJr/YpoRglAssuFxCIyg=
>=4R2b
>-----END PGP SIGNATURE-----
>
>
>  
>

Re: [mina] changing groupId

[Brett Porter <br...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alex,

>
> 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.

This is really a deficiency of the current plugin - it should only link
other projects built within an idea:multiproject run (or eclipse
equivalent), and deps for everything else, or at least follow a
configuration item. Fixing the plugin may be a better alternative than
working directory around it if that is the only issue.

>
> 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.

If group ID's are still changing, can I request that you mirror the
package? ie org.apache.directory.naming, org.apache.directory.network,
etc. Or just org.apache.directory if it is decided to share them.

>
> Now we could set a general rule where every trunk has its own groupId.

This seems a good rule in general, regardless of the current split.

> 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.

The only way to maintain a versionable parent POM here with Maven 1.x is
to make a copy of the files when it changes (project-1.0.xml,
project-1.0.1.xml), as it shouldn't happen too often. Alternatively,
manually merge the POM in the tags directory after a release, or just
merge them now and maintain separate copies.

>
> Anyone have comments on how to resolve these problems?

I'm not entirely certain the "shared" structure is right, or the number
of trunks. The fact that everything is being versioned together
indicates their development is really tied to each other - at least at
this point. The only exceptions seem to be naming (separate from the
start), mina and maybe asn1 (which has been branched a few times). In
this instance, I'd expect to see a single trunk with the project
hierarchy underneath it.

The tree has been changing constantly over the past few months. I'd
suggest sitting on it right now - the problems that exist with IDEs can
be fixed, and the shared/project.xml is not really a big issue until it
comes time to make a release. Learn what works and what doesn't, and
approach it again later with a more wholistic view.

- - Brett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCQVzsOb5RoQhMkRMRAq/jAKC0Otq49BhmGjqvxEgmZUrr3t4OwACgmRqk
os3kJr/YpoRglAssuFxCIyg=
=4R2b
-----END PGP SIGNATURE-----