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 <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<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
> now. <http://clk.atdmt.com/GBL/go/196390709/direct/01/>
>
>
>
> --
>
> 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.
>
>
>