[
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
|
On Jul 17, 2009, at 11:53 AM, Jeff McAffer wrote:
But importantly, the jars available from the eclipse repository
might differ from those available elsewhere, because they may
have been through eclipse conditioning. It is very important
that this difference be flagged in the either groupId, artefact
ID, classifier or version. So for example a jar available
from maven central repository as
javax.servlet:servlet-api:2.4
when placed in the eclipse repository might be classified as
javax.servlet:servlet-api-eclipse:2.4
You are supposed to release stuff like this under your own groupId,
e.g.
org.eclipse.specs.javax.servlet
although I personally like geronimo's spec naming convention.
Care to share what that convention is?
groupId: org.apache.geronimo.specs
this clearly identifies the organization that the artifact is from,
unlike the random assortment of groupIds favored by sun.
artifactId: geronimo-<spec-name>_<spec-version>_spec
e.g. geronimo-jaspic_1.0_spec
The "geronimo-" part is a bit redudant but provides even more clear
indication of the provenance in the artifact file name. The "_spec"
part is also a bit redundant given the .specs in the groupId but also
serves to clearly separate the spec version from the jar version in
final file name.
version: starts at 1.0 or 1.0.0, proceeds upwards as we fix bugs,
improve packaging, etc.
This recognizes that just because a spec jar works fine in a tck
compliant app server, it can still be full of bugs and the spec
version is by no means sufficient to identify the actual jar you want
to use. IIUC sun prefers to release lots of jars, schemas, and
possibly specs that claim to be the same thing but have plenty of
changes inside.
type: so far all the specs are jars, although the maven packaging type
for the geronimo specs is "bundle" as we use the maven-bundle-plugin
to generate the osgi metadata.
Related to this, the last time I looked seriously at Maven there was
a split in the community as to the use of group and artifact ids in
the case of bundles. Core to this is the expectation that the
actual file on disk has the name dictated by the artifact id (of
vice versa). As you know, eclipse bundles (JARs) tend to have names
that match the bundle symbolic name. If I understand the syntax,
that would lead to something like
javax.servlet:javax.servlet:2.4
otherwise the JAR on disk would be servlet-api.jar or some such.
While of course the runtime does not actually require that the BSN
and file name match, it has caused great confusion in the past when
they do not. Especially if sometimes they do (for the same bundle).
What do you mean by the "same bundle"? Has eclipse released the same
binary content under several packagings? Or are you talking about
several bundles with the same bundle symbolic name but different
versions?
Consistency is king.
All the apache projects I know of that are even vaguely osgi friendly
and use maven use the felix maven-bundle-plugin. After a lot of
possibly heated discussion they came up with a convention for deriving
the bundle symbolic name from the maven artifact coordinate:
# <Bundle-SymbolicName> is computed using the shared
Maven2OsgiConverter component, which uses the following algorithm:
Get the symbolic name as groupId + "." + artifactId, with the
following exceptions:
* if artifact.getFile is not null and the jar contains a OSGi
Manifest with Bundle-SymbolicName property then that value is returned
* if groupId has only one section (no dots) and artifact.getFile
is not null then the first package name with classes is returned. eg.
commons-logging:commons-logging -> org.apache.commons.logging
* if artifactId is equal to last section of groupId then groupId
is returned. eg. org.apache.maven:maven -> org.apache.maven
* if artifactId starts with last section of groupId that portion
is removed. eg. org.apache.maven:maven-core -> org.apache.maven.core
The computed symbolic name is also stored in the $(maven-
symbolicname) property in case you want to add attributes or
directives to it.
(from http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)
So as long as the JAR is the right (aka consistent) name on disk, it
does not matter what the group id is (at least from my point of view)
Hopefully your view of "right" is consistent with what the maven and
felix communities came up with :-)
thanks
david jencks
Jeff
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev
