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. > > 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
