Re: [eclipse-pmc] Migrating to Jetty 8, Servlet 3.0, JSP 2.2

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I have commented in the bug. I'm not sure
if we can do much other than rolling with the version change. We'll have
the same issue for Lucene 3.x assuming we get it adopted in time for Juno.
We have to live with the version numbers that third party libraries give
us. As I mentioned in the bug, I believe our current recommendation is
to *not* specify any upper bound when declaring a dependency on third party
libraries - just use "2.5" rather than [2.5,3.0).

John

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

10/10/2011 11:03 AM

Please respond to
eclipse-pmc@xxxxxxxxxxx

To	eclipse-pmc@xxxxxxxxxxx
cc
Subject	[eclipse-pmc] Migrating to Jetty 8, Servlet 3.0, JSP 2.2

We have been making progress in migrating to Jetty 8 in
bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=309529

There is an issue of compatibility that I want to bring to the Eclipse
PMC's attention. In moving to Servlet 3.0 we will need to upgrade the javax.servlet
bundle we ship in the Eclipse SDK to version 3.0. This bundle (from orbit)
currently exports the javax.servlet packages at package version 3.0. While
this seem to make sense on the surface it does not make sense from a binary
compatibility story since Servlet 3.0 specification is binary compatible
with the Servlet 2.5 specification. It is possible that the community has
client application bundles that use the serlvet/jsp support in Equinox.
If they are following the best practice for importing the javax.servlet
packages then they should be using an import package range like "[2.5,
3.0)". Such a client application bundle will get burned by our move
to servlet 3.0 and would have to update their own bundles to allow for
the import of the 3.0 javax.servlet packages.

The discussion in going on in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245.
I plan to discuss with the glassfish team to figure out why the exported
the package at versoin 3.0 instead something that indicates the correct
evolution of the package (e.g. 2.6). My assumption is that they will not
be changing to a package version less than 3.0 for the javax.serlvet 3
bundle. So do we view this as an acceptable breaking change for the Juno
release? The impact really depends on how many client bundles we have that
are using Import-Package with the best practice range for client application
bundles.

Tom
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc