Steven,
looking at the existing feature set of Jersey I think the questions are
already answered by the facts:
* Jersey *is* the RI and there is no change in sight regarding that point.
* Jersey *is* already much more than the RI (e. g. JSON, ATOM, Client, etc.)
and it is obvious that most development happened and will happen outside of
JAX-RS, as JAX-RS makes only small steps forward compared to the
non-standard features.
BTW, funny to follow this discussion, as it covers exactly why I decided to
spin-off "WebDAV Support for JAX-RS" from being a former Jersey module to
being a standalone library meanwhile:
- Shall have it's own version number
- Shall only be dependent of JAX-RS, but not of Jersey (run with any JAX-RS
engine)
- Shall have it's own release cycle
I was suggesting to start a new java.net project for all the modules, and
truncating Jersey to become solely the RI. While Paul supported the idea of
having a Jersey-independent java.net project for JAX-RS extensions, he
didn't liked the idea to strip everything but the RI from the Jersey
project. So that other project was never started, but just WebDAV was
stripped (since it was under my sole control, see
http://webdav.dev.java.net).
So I think that answers you question on the future of Jersey?
Regards
Markus
From: Steven Cummings [mailto:estebistec_at_gmail.com]
Sent: Samstag, 9. Januar 2010 21:36
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
Yeah, I assume he meant <version>, or more generally <dependency> with
artifact, group, version, etc. I also assume Jersey will always advertise
what version of JAX-RS it is a provider for in its own POM, so in the strict
technical sense there should never be a problem in that respect.
It sounds like we're asking broader questions here that need to be answered
before a versioning scheme is implemented:
* How closely tied to jax-rs's development will jersey remain? It is
the RI, so if it is to remain so, then I would think it should stay pretty
close (again, I'm not speaking in versioning implementation here...)
* What, exactly, is the scope of this new life that jersey is taking
on?
* Does it overtake jersey's role as RI, or will it be okay that major
*jersey* features will only be available at or above certain jax-rs
versions?
There are probably more questions, but may main question is this: What is
the center of jersey's existence to be? Primarily the RI of jax-rs or its
own set of growing features that happen to be a provider for jax-rs? That's
not a rhetorical question, but it is one that I think bears clarification
before deciding on version schemes.
Apologies if that was answered elsewhere, but given the questions I'm seeing
on this topic, it *seems* that it needs discussion.
--
Steven
On Sat, Jan 9, 2010 at 8:24 PM, Markus Karg <markus.karg_at_gmx.net> wrote:
Now it really gets weird.! If you do *not* want to link the version numbers,
why do you want to add *any* version number in <artifactId> (in exactly THAT
XML element)? I think that you meant <version> instead?
From: Hubert.Levangong_at_Sun.COM [mailto:Hubert.Levangong_at_Sun.COM]
Sent: Samstag, 9. Januar 2010 19:16
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
Since Jersey now has its own life I tend to agree with Kumar that
we should only carry Jersey's version in the <artifactId> element
and make sure the rest is properly documented.
My 2 cents,
Hubert
On Jan 9, 2010, at 6:54 PM, Sudhakar Kumar wrote:
I definitely appreciate your intention towards an alternate proposal that
leaves the versioning as in Maven Best Practices.
My point being, many artifacts are needed when implementing a solution. Just
adding jax-rs to jersey doesnt solve the problem when you look at it
generically. A developer still needs to understand the version of JRE
supported by a specific version of Jersey and so on.
In other words, if the idea is to say Jersey/JAX-RS are the only two first
class citizens that we are trying to explicitly indicate via a change to
artifact ids, I am not sure what that buys in the overall scheme of a
developers life cycle. The 'programmer' still has to see beyond Jersey and
JAX-RS. That's all I am trying to point out.
_____
From: markus.karg_at_gmx.net
To: users_at_jersey.dev.java.net
Date: Sat, 9 Jan 2010 18:30:43 +0100
Subject: RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
You oversee one point: My proposal is *not* a new creation of definition, it
just adds an indicator to the name of the jersey bundle indicating which
specification (JAX-RS 1.1) it is implementing. In terms of Microsoft, it
would be "jersey-vista" compared to "jersey-xp", and I doubt you would have
something against that, as vista and xp are as clearly separate things as
JAX-RS 1.0 and 2.0 would be. Also, the proposal was only made due to the
fact that there *are* programmers that like to see that dependency (while I
personally don't need that since I am able to look into a POM file's
dependency section to find out that information). My original proposal was
to *not* fumble around with versions at all but just apply the Maven Best
Practices as they are.
Regards
Markus
From: Sudhakar Kumar [mailto:ksudhakar_at_live.com]
Sent: Samstag, 9. Januar 2010 18:10
To: users_at_jersey.dev.java.net
Subject: RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
Innovative thoughts Markus. But. . .
So what next? Relate Jersey release with the JRE release?
I think as developers we have a responsibility to understand and decide the
version of software we need to use in development and assembly process. It
is an important decision. If we need to facilitate the process of making
this decision, then we need to do so through appropriate documentation - say
within the download site.
Versioning is not limited to JAX-RS and Jersey. My two cents is to not
create a new definition of 'versioning' specific to jersey and jax-rs. These
are two distinct entities, just as jersey and jre.
> From: markus.karg_at_gmx.net
> To: users_at_jersey.dev.java.net
> Date: Sat, 9 Jan 2010 09:44:11 +0100
> Subject: RE: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
>
> Tatu,
>
> I think I have found a solution that will make all of us happy and want to
> propose it as a concensus. But before I propose it, first let me answer
your
> point:
>
> Sync'ed versions imply one severe problem: Jersey is not just JAX-RS, it
> also contains lots of other functionality. What will you do if there is no
> JAX-RS progress for long time, but there are heavy changes in the other
> areas of technology which would mandate a major or minor version change?
> Currently Jersey will reflect this using the two left over version pieces
> (bugfix and build), but this means those cannot be used for what they are
> there: What will you do in case of a real bugfix...? You wouldn't just
have
> left over a peace of information to reflect it! Following this
argumentation
> there just is no space left over (unless you extend the version number to
> SIX pieces, and here comes my proposal into play).
>
> My proposal is, to move JAX-RS's version number into the NAME part of the
> file, so the name will be sync'ed with the JAX-RS version number, while
> Jersey's own version number has left it's full four parts for it's own and
> intended use. Example:
>
> <artifactId>jersey-jaxrs-1.2</artifactId>
> <version>3.4.5-6</version>
>
> will be Build No. 6 of Jersey Release 3.4's Bugfix No. 6, which is the RI
of
> JAX-RS Release 1.2 !
>
> As a JAX-RS version change actually is a specification change, it makes
> pretty much sense that the artifactId will change. Just as Microsoft's OS
> was no more called Vista but Seven after the SDK's API specification
number
> changed, while there was no rename just for the ServicePacks and BugFixes
> before (and no, I don't think that technically Windows Seven is worth to
> change version from NT6 to NT7, but rather would have chosen a minor
number
> of NT6.5 ;-) ).
>
> Ain't that the non-plus-ultra solution?
>
> It is 100% Maven 2 compatible (as Maven allows virtually anything inside
of
> the artifactId, as it is a different coordinate, separated from the
> version), and the resulting file name would look like this:
>
> jersey-jaxrs-1.2-3.4.5-6.jar
>
> So there is no more need to neither break sync'ing with JAX-RS, nor for
> artificially increasing the version to 3.0 without a real change!
>
> The drawbacks would be: One cannot say "I want ANY Jersey" without
> specifying the JAX-RS version number. But hey, would that make any sense
at
> all? I mean, even a minor change in JAX-RS should imply a careful decision
> whether to actually use it or not, and not let it open to Maven, while it
> makes pretty much sense that inside that manually chosen specification
> version, Maven shall automatically select it's latest RI.
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com]
> > Sent: Freitag, 8. Januar 2010 20:07
> > To: users_at_jersey.dev.java.net
> > Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
> >
> > On Fri, Jan 8, 2010 at 5:50 AM, Tim Edwards
> > <Edwards.T_at_cambridgeassessment.org.uk> wrote:
> > > It might be that I was missing the obvious but personally I never
> > realised
> > > there was a correlation between JAX-RS and Jersey versions.
> >
> > Perhaps I am in minority, but I would expect Jersey to somewhat follow
> > JAX-RS versioning scheme, given that it is currently feasible. If
> > there were other major changes that would warrant major version
> > upgrade, then this would have to change.
> >
> > So my opinion is that (a) Maven-style versioning makes sense -- major
> > version for major non-compatible changes, minor for additional
> > functionality (backwards compatible), and so on and (b) having Jersey
> > version relate to JAX-RS version is a nice to have thing too.
> > And obviously if/when JAX-RS API change to 2.0 is a major incompatible
> > one, it should bump Jersey into new version anyway.
> >
> > -+ Tatu +-
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
_____
Hotmail: Free, trusted and rich email service. Get it now.
<http://clk.atdmt.com/GBL/go/196390708/direct/01/>
_____
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
<http://clk.atdmt.com/GBL/go/196390709/direct/01/> now.
--
Hubert A. Le Van Gong
Identity Architect
Sun microsystems, Inc.
17 Rue Duprey
Grenoble, 38000
France
--------------------------------------------------
email: hubert.levangong_at_sun.COM
tel:+33 4 7663 0935
blog: http://blog.levangong.com/
N 45 11.900'
W 005 44.145'
Elev. 736 ft.