[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

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?

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). Consistency is king.

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)

Jeff