On 5/5/10 15:27, Chris Custine wrote:
AFAIK, there is no domain called org.apache.felix.karaf.jaas. What if
someone else actually owns such a domain name and now wants to publish some
artifacts under that groupId?
They would have to control Apache DNS servers! :-)
Seriously though, I see merits in both sides of this conversation, but the
fact is that each project (and in this case, maybe even sub-projects) has
different needs. Many other projects employ a combination of the 2
approaches talked about here and there are no real hard and fast
requirements for maven groupId naming. The Maven developers themselves
don't even strictly follow the groupId == reverse domain recommendation. (
http://repo2.maven.org/maven2/org/apache/maven/wagon/) IMHO that is an
oversimplified interpretation of what is said on that page.
So I don't think there is a right or wrong answer. Must we really spend
time pursuing these pedantic discussions when there is little or no
constructive outcome no matter what the end result is?
I agree that this isn't the most important topic in the world, but so
far the conversation has been pretty calm so I don't think the
discussion has given cause for concern.
For me, it comes down to a matter of consistency. I don't want each
subproject making some arbitrary decision to use their own sub-groupId
just because they can. This just makes life difficult on a daily basic
when trying to specify dependencies in pom files. It would be nice to
have some understanding of when this make sense, e.g., why wouldn't I
create a groupId of org.apache.felix.fileinstall for File Install to
give it "its own identity"?
Personally, I think people are placing too much value on having their
own groupId, since the only place this really matters is if you are
browsing a Maven repo. This is a pointless detail...if they change how
they store artifacts in the next release of Maven then all of this extra
meaning people are conferring upon it will be lost.
-> richard
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, May 5, 2010 at 12:59 PM, Sahoo<sa...@sun.com> wrote:
AFAIK, there is no domain called org.apache.felix.karaf.jaas. What if
someone else actually owns such a domain name and now wants to publish some
artifacts under that groupId?
Thanks,
Sahoo
Guillaume Nodet wrote:
One could argue the domain name is org.apache, so it's clearly controlled.
On Wednesday, May 5, 2010, Sahoo<sa...@sun.com> wrote:
Is there a domain name for each of those groupIds? Unless one controls
the domain name, it should not be used as the groupId as per [1]. So, I
would expect all the groupIds to be org.apache.felix for all Felix
subprojects.
Thanks,
Sahoo
[1]
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Guillaume Nodet wrote:
btw, even in karaf, we have sub-sub groupids, for example:
org.apache.felix.karaf.jaas
On Wed, May 5, 2010 at 17:38, Guillaume Nodet<gno...@gmail.com> wrote:
Yes, you don't end up with 100s of jars in org.apache.felix,
so it's better categorized.
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
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
