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.
But solving issues like this is exactly what Maven's version ranges are good
for: You can set e. g. [1.1, 1.1.5][3.0, 4.0) - or even easier: [1.1, 4.0)
as Paul guarantees there will be nothing between 1.1.5 and 3.0 - for example
to designate the API you want to bind against, and Maven will choose the
latest bug fix automatically -- and thanks to the second interval, you even
won't notice the step from 1.1.5 to 3.0. So if you copy the above range to
your project now, your concerns will be solved.
> ...
> >> 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).
Interesting thoughts... actually your proposal solves three of the reasons
why WebDAV had split off from Jersey a year ago: the non-Maven-versioning
schema, enforcing the same version for all modules, and enforcing coupled
release cycles. If Paul will accept your proposal, chances arise to
reintegrate WebDAV into Jersey. ;-) (Frankly spoken, there are much more
reasons not to do that step).
> 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 +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net