Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse

Jesse McConnell wrote:
> imo, the servlet-api as it exists as a eclipse bundle would slot into
> the maven repo something like...
> 
> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5.0.v200806031605/servlet-api-2.5.0.v200806031605.jar
> 
> however I would be +1 for having eclipse somehow indicated in that
> version string... maybe 2.5.0.v200806031605-E
> 
>> Is all this captured in the POM?  Is anything else needed other than more
>> data in there
>>
> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5.0.v200806031605/servlet-api-2.5.0.v200806031605-javadoc.jar
> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5.0.v200806031605/servlet-api-2.5.0.v200806031605-sources.jar

Jesse,

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



cheers





Back to the top