On 5/5/10 12:40, Guillaume Nodet wrote:
On Wed, May 5, 2010 at 18:33, Richard S. Hall<he...@ungoverned.org> wrote:
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.
Most of the users of the projects i've been working on the past years use
maven, so they do know about groupIds and artifactIds.
But you certainly can't be arguing that we expect users to know Maven to
understand the structure of our projects! :-D
-> richard
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
