On 5/5/10 12:14, Guillaume Nodet wrote:
On Wed, May 5, 2010 at 18:03, Richard S. Hall<he...@ungoverned.org> wrote:
On 5/5/10 11:38, Guillaume Nodet wrote:
Yes, you don't end up with 100s of jars in org.apache.felix,
so it's better categorized.
I think we can't help but categorize our artifacts, since they are long
names, e.g.:
org.apache.felix.framework-2.0.5.jar
So all "gogo" JARs are categorized automatically since their JAR files all
of the form:
org.apache.felix.gogo.*.jar
I guess I am not sure why we worry about how Maven organizes its
repo...seems like an implementation detail to me.
Agreed, as is the groupId really. There are a lot of subprojects in the ASF
that don't even start with their TLP ;-)
I think it's just makes things more difficult for users. I'm not sure we
have anybody out there that downloads all the iPojo jars one by one, so
trying to make those first class citizens does not make sense to me (i'm
referring to the main download page). I have actaully done the same for
gogo, even if i also think it's useless (just to be consistent and not start
such discussions). Adding the 20+ jars from Karaf would not make sense
either imho.
Subprojects that are composed of multiple bundles are not necesseraly meant
to be consumer by picking the bundles one by one. That would anyway still
be possible because all the bundles are available from maven, and users that
start doing such things are well aware of that usually.
So really, I think subprojects should have more of their own identity. The
fact that they belong to a given TLP is mostly irrelevant for the end-user.
To me it isn't really about issues of identity or even organization, it
is only about specifying dependencies in pom files and know which
groupId to use...I like to remember as few things as possible. Clearly,
though, it's not the end of the world either way since a little poking
around will help you figure out the groupId if you get it wrong.
As far as the end user is concerned, all they see is the name of the JAR
file and they don't have any idea about groupIds etc., so it doesn't
really help them in anyway.
Regarding trying to view sub-groupIds as being for collections of
modules that aren't intended to be used independently. I understand what
you are saying and in terms of Karaf in perhaps makes sense, but in
general i'd hope that people design all of their modules with the idea
that they can reused independently in new contexts. For example, the
simple Gogo commands module I just committed, if the RFC actually
becomes an OSGi spec, then they it would work with any impl, not just Gogo.
At any rate, I'd argue against using sub-groupIds just from a conceptual
overhead perspective and will likely continue to not use them myself
since I don't really see any added value.
-> richard
-> richard
On Wed, May 5, 2010 at 17:20, Richard S. Hall<he...@ungoverned.org>
wrote:
I noticed while poking around Gogo that its Maven groupId is:
org.apache.felix.gogo
While most other subprojects are:
org.apache.felix
Apparently, Karaf also creates its own groupId. I guess I was under the
assumption that all subprojects were using the same groupId. It doesn't
seem
necessary, even if you have multiple modules, since for example iPOJO has
multiple modules, but still uses org.apache.felix.
I realize the groupId doesn't really have much impact, but it does make
it
somewhat confusing to know which is the correct groupId to use for a
given
subproject. So, from that perspective it seems easier and more consistent
if
every subproject just used the same groupId. Are there any benefits of
having separate groupIds?
-> richard
