| Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse |
> While that is indeed the structure that we currently work with, I'm attracted > to the naming scheme used by eclipse that David has outlined. > > So we would have something like: > > http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0.jar > http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0-javadoc.jar > http://maven2.eclipse.org/org/eclipse/orbit/servlet_2.5_spec/1.0/servlet_2.5_spec-1.0-sources.jar > > Note that I have put orbit in the group name, as this indicates a jar > audited and redistributed from eclipse - as opposed to one generated by > eclipse. I've not put eclipse- on the front of the artefact name > because I think there will be ample indication of the jars source (the > directory it is in, the MANIFEST.MF and the META-INF/pom.xml will all > record groupId and/or bundle id). > > Currently the bundle name we put into the mortbay servlet api is > > org.mortbay.jetty.servlet-api > > but if we apply the "rules" suggested by david, it should be: > > org.eclipse.orbit.servlet_2.5_spec > > This is a good bundle name (in my non-OSGi experienced eyes), as it identifies > both where it came from and what it is. > > For specification APIs at least, the geronimo artefacts have become > (or are becoming), the defacto canonical source of jars. They are the > only organization that has systematically and consistently made these > jars available (see http://repo2.maven.org/maven2/org/apache/geronimo/specs/) > We could do worse than follow their model. > > Of course we need to extend this model to encompass jars other than > specfications, but the model works equally for > > http://repo2.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar > > would become > > http://maven2.eclipse.org/org/eclipse/orbit/commons-logging/1.1.1/commons-logging-1.1.1.jar > > > I am not a terrible fan of finding the same dependency scattered all over the place in different locations in the repo, but perhaps in this instance where the artifacts in question have been altered from their original form a la eclipse bundling and conditioning...this would let anyone specifically looking for eclipse bundles go to a special location in the repo and see their options I'll agree with that :) jesse