On Mon, Jan 11, 2010 at 9:47 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
> Tatu,
>
>> That is: when JAX-RS major version changes, yes, I would fully expect
>> Jersey (core) major version to advance. That is by definition a major
>> version change trigger (for Maven et al).
>
> This is an interesting point. I understand that when the software actually
> has a major change, then the version number must update. But in fact I doubt
> that it is a real problem that the version number changes without a software
> change. I mean, the first case prevents a problem, but the second...? What
> real problem will arise from your point of view, in case the version
I think the main (and perhaps only) problem would be inconvenience, if
you have to depend on Jersey.
Downstream systems would then have to update their dependencies to
either include both older and newer version, or to upgrade to newer;
but these without getting any benefits.
Such dependencies may not be common, since Jersey is not a low level library.
And I wouldn't see it as a big problem... probably more as irritation,
as in "why do they bump version number like Microsoft?" :-)
...
>> And client versioning should not be artifically kept in sync if (when)
>> it develops at significantly faster pace. So there is nothing wrong
>> with having, say, Jersey-client 4.0, that would use JAX-RS 2.0 API.
>
> I think this is a good idea. In fact, modularization would be beneficial, e.
> g. for smaller footprint and loading time etc. So maybe Jersey should get
> completely split into different JARs, like "jersey.jar" for only the JAX-RS
> implementation, "jersey-servlet" for the engine based on Servlet API,
> "jersey-grizzly" for the engine based on Grizzly API, "jersey-json" and so
> on? Sounds like a good idea and clearly solves the problem of the
> dependencies. But also sounds like a rather big bunch of work...
I think pieces will be refactored over time. But you are right that it
can be lots of work, and without immediate major gains. I have done it
with some of my open source projects, and it takes time (like Woodstox
4.0 splitting out Stax2 extension API, because it started to be needed
by other projects like taxMate).
I agree in that such modularization is a good thing, esp. when done
with pragmatic view: as in not done only because it is correct
semantically, but because it has some value. In this case it would
decouple release cycles, which already seem somewhat separate.
Especially because server side is more coupled with JAX-RS
specification than client side (client side not being covered by the
spec).
Anyway: like everyone else except for Paul and Jakub, these are just
my opinions -- and in the end, versioning is not the most important
thing here. So far Jersey has progressed very nicely, and its
versioning scheme so far has worked pretty well. It's just question of
finding solid improvements where they can be found.
-+ Tatu +-