Craig,
From: Craig.McClanahan_at_Sun.COM [mailto:Craig.McClanahan_at_Sun.COM]
Sent: Montag, 26. Januar 2009 00:06
To: dev_at_jersey.dev.java.net
Subject: Re: [Jersey] WebDAV pom.xml
Markus KARG wrote:
Well, this depends on what Paul and Marc want to make out of Jersey: If they
want to make it a collection of JAX-RS utilities ontop of a JAX-RS
implementation, then I do not see that a split is needed. Actually it was a
standalone project before (internally hosted by us, not publicly available)
and I asked whether I shall make a standalone project or contribute to
Jersey. It was Paul that said that he likes it to be part of Jersey. So I
have to wait for his decision how he will deal with the fact that it can run
with other JAX-RS implementations and has its own version schema and
livecycle.
My personal feelings about this -- if a module lives in a Jersey namespace
(Java package name and/or Maven group and artifact identifiers), ships with
Jersey (presumably a goal at some point in the development process), and has
its source somewhere in the Jersey trunk (presumably would happen with a
merge to trunk from the current branch), then that module should carry the
same version number (and release timelines) as the rest of Jersey. Further,
I would think the package names, as well as other conventions such as JDK
dependencies and common build plugins, should also match.
Since the namespace and storage location is something that can easily be
changed, I do not think that it should be the argument for the version
number, as it is not an invariant -- if it turns out that the WebDAV stuff
just is better kept in a different place, I can make my own project out of
it. The namespace and storage location was chosen by Paul after I offered to
add my previously standalone code into the Jersey project. This can be
changed at any time, if needed. Actually this discussion is more about
whether Jersey will stay a single product or become the host for subprojects
(what I now see might be needed, at least for WebDAV, as there is just no
relation to the Jersey codebase at all). You try to force WebDAV into the
Jersey rules just for the sake of making it a Jersey part, but technically
it just is none and the technical constraints do not make any sense from the
WebDAV inside viewpoint. Do you also replace the motor of your car just
because you park it in another vendor's Garage? I do not see that this
argumentation makes sense. We should concentrate on the technical facts, and
this is that WebDAV has nothing to do with the Jersey code or build
structure. So this shouldn't get enforced. In fact, I spent more time into
making WebDAV a good Jersey-build-structure-citicen than I spent into its
coding.
The fact that the module may or may not have any dependencies on Jersey
internals is an implementation detail (and that of course gets reflected in
the <dependencies> section of its POM) that may or may not change in the
future. That by itself should not be a deciding factor on versioning, or
for that matter naming.
Well, as long as I am the sole author of WebDAV (what seems to stay
unchanged looking for the near future) I can guarantee that it will never
use any Jersey internals, as it is an intended target of my work that WebDAV
can run on ANY JAX-RS implementation and it SHALL NOT use anything outside
of JAX-RS. So it IS a major decision for versioning, as people want to know
what the status of the WebDAV JAR is when downloading it -- they would not
see this when I put some fancy numbers at the JAR that express a progress
where there is none in reality.
If the module wants the "marketing" benefits :-) of being part of Jersey,
instead of being standalone, then it should really *be* part of Jersey.
Even if (at the moment) it will actually run on any JAX-RS implemenetation
(and therefore declare only the API jar in its dependencies).
I never asked for any marketing benefits, and I really dislike allegations
like this. In the beginning of the project I publicly asked what the
majority of the Jersey developer want my code to become - part of Jersey or
standalone (as it was standalone before, but not published). They wanted to
have my WebDAV code to be part of Jersey. That was the SOLE reason why I
contributed it. I did never plan to make it part of the Jersey product, but
only of the Jersey project. This is a huge difference.
This particular codebase is off to a very promising start, and is something
I would personally like to see in Jersey (with, as usual for me, some love
for the client side too :-). But I'd prefer to see it "all in" rather than
being perceived as straddling a fence.
This would result in the fact that only Jersey users will be able to use
WebDAV while the users of other JAX-RS implementation couldn't use it. This
is not in the sense of the JAX-RS standard. So it cannot become a real part
of it.
Regards
Markus