directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [mina] changing groupId
Date Wed, 23 Mar 2005 18:02:10 GMT
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-----
>
>
>  
>


Mime
View raw message