users@jersey.java.net

Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th

From: Hubert Le Van Gong <Hubert.Levangong_at_Sun.COM>
Date: Sun, 10 Jan 2010 16:50:09 +0100

Yes I meant <version>.

As for the scope, I think the goals listed on the front page of the
Jersey site help:
- RI for JAX-RS,
- APIs to develop extensions
- Make it easy to build Java-based RESTful web services.

Hubert


On Jan 9, 2010, at 9:36 PM, Steven Cummings wrote:

> 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.
>
>
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign
> up 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.
>
>
>

--
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.