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
advances without any software change? Microsoft even completely renamed it's
operating system from Vista to Seven without anything noticeable besides bug
fixes and design overhaul and not only nobody has a problem with that but
moreover people actually loved that and likes to buy it now (while they did
not when it was named Vista). Following that logic, developers should love
it that Jersey increased it's version number without any noticeable
modification. ;-)
> Existence of extensions beyond core JAX-RS (esp. client side)
> complicates things obviously. I would think that it would make good
> sense to separate client-side package more from core and server side.
> 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...
Regards
Markus