[wtp-dev] changes coming to javax.servlet in Juno M4

[David M Williams <david_williams@xxxxxxxxxx>]

Heads up ....

As mentioned in the status meeting today, Equinox will be picking up a new
version of javax.servlet (and hence, will be in "the platform" we use).

This just today showed up in an Orbit I build, which will become Orbit's S
build on Friday (unless someone contributes something else soon).

http://download.eclipse.org/tools/orbit/downloads/drops/I20111201180206/


This won't show up in platform builds until next week (not in the one Carl
said he'd update to tomorrow, on Friday) .... so, thought I'd send this
early warning.

Just with what I happened to have loaded in one of my workspaces, and doing
a text search, I saw two bundles this will effect (might be more):

org.eclipse.jst.jsf.core
org.eclipse.wst.server.preview

They have "require bundle"
 javax.servlet;bundle-version="[2.4.0,3.0.0)"
 javax.servlet;bundle-version="[2.5.0, 2.6.0)"

Both will break with M4. The new javax.servlet _bundle_ will be version
3.0.0 but the _packages_ inside will be exported at version 2.6 (all
discussed in bug 360245 [1]).

It has been recommended that if you use "required bundle" for
javax.servlet, that you leave it "open ended", similar to ICU
recommendation (since they do not well follow the "Eclipse, or OSGi,
versioning semantics".
So, the above would become
 javax.servlet;bundle-version="2.4.0"
 javax.servlet;bundle-version="2.5.0"


It would be even better to convert these "foundation libraries" to "import
package" instead of require bundle (you normally don't care where they come
from) ... but ... I know less about possible side-effects of that :/

So you might want to make use of recent Orbit build (or, at least, the S
build declared tomorrow, 12/2) to "test" your prereq versions locally (by
putting the new stuff in runtime target) and
get some of these version issues fixed early, since next week will be a
short, "final week" before M4.

Thanks,


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245