I remember discussions about groupids and artifact ids mostly in relation to 
the bundle symbolic name (which imho is more important in the end because this 
is about Felix => OSGI). The problem is that there is no nice mapping between 
the bsn <-> artifact/groupid. In this ancient discussion we defined a mapping 
scheme as I recall which ended up with the current scheme. 

In bnd I have a maven plugin that can work with maven repos but I need to map 
the bsn to the maven ids to traverse the repository efficiently. Currently I 
use the org.apache.felix prefix and some others. If every subproject defines 
their own mapping of bsn <-> artifact/group id then this will all become 
significantly harder.

Last but not least, consistency has tremendous value because you spot errors 
more quickly and you minimize the learning curve. And it is easier to automate. 
I actually do not care what mapping is chosen for the bsn but from an OSGi 
point of view I think consistency in the Felix project (which sets an example 
for other projects) has great value.

Just my 2cts.

Kind regards,

        Peter Kriens



On 5 mei 2010, at 23:44, Richard S. Hall wrote:

> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>         
>>>> 
>>>> 
>>>>       
>>>     
>>   

Reply via email to