directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [mina] changing groupId
Date Wed, 23 Mar 2005 12:11:24 GMT
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,,
etc. Or just 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

Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird -


View raw message