[
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