[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Rethinking the Servlet API packaging



Hi all,

I'm starting to plan the packaging of Tomcat 9 which should be the
version of Tomcat shipped with Buster. Before doing that I'd like to
rethink how the Servlet/JSP API are packaged in Debian. Historically the
tomcat packages have been the source of the libservlet<n>-java packages:
* src:tomcat6 had libservlet2.5-java containing the Servlet 2.5,
  JSP 2.1 and EL 2.1 APIs
* src:tomcat7 has libservlet3.0-java containing the Servlet 3.0,
  JSP 2.2 and EL 2.2 APIs
* src:tomcat8 has libservlet3.1-java containing the Servlet 3.1,
  JSP 2.3, EL 3.0 and WebSocket 1.1 APIs (the WebSocket API is wrongly
  numbered 1.0 in our package)

Before tomcat6 there was a standalone src:javax-servletapi2.2 package
building libservlet2.2-java with the Servlet 2.2 and JSP 1.1 APIs. It
came from the Apache Jakarta project, when Tomcat wasn't yet a top level
Apache project. At this time the Servlet API was a separate dependency
of Tomcat.

So far the libservlet<n>-java packages always included several APIs
(Servlet, JSP, EL and now WebSocket) at different versions and that was
fine. With Tomcat 9 this model derails a bit because while the Servlet
API is upgraded to the version 4.0, the version of the JSP, EL and
WebSocket APIs don't change. So if the src:tomcat9 package was to build
libservlet4.0-java, it would conflict with libservlet3.1-java, or depend
on libservlet3.1-java which would prevent the removal of src:tomcat8.

Another notable annoyance with the Servlet API packages is the recurrent
burden of the transitions to a higher version. There are about ~100
packages that build depend on the Servlet API. For each transition,
that's roughly once per release cycle, we have to update the
dependencies and quite often also add stub methods to fix the source
compatibility [1][2]. It would be much easier to keep several versions
of the Servlet API in the archive and avoid this extra work, something
we are reluctant to do because it drags the full source of ancient
Tomcat releases in Debian. We kept the src:tomcat7 package for
libservlet3.0-java, but that's still a bit odd and a source of confusion
(a tomcat package that doesn't actually build Tomcat always raises
questions).

So I'd like to take the opportunity of the Tomcat 9 packaging to suggest
the following changes:
* The src:tomcat(n>=9) packages no longer build libservlet<m>-java.
* The Servlet, JSP, EL and WebSocket APIs are packaged separately,
  using the JavaEE (now Eclipse EE4J/JakartaEE) repositories on GitHub.
  These API packages are kept in the archive as long as necessary. Being
  pure API with no actual implementation, they aren't security sensitive
  and don't create a maintenance burden.
* When src:tomcat(n<9) is removed, introduce standalone API packages.

In details, that would give:

1. Create a new src:servlet-4.0-api package building libservlet4.0-java
   with the Servlet API *only*, no JSP/EL/WebSocket API, not even as a
   dependency.

2. libservlet3.1-java gets split into 4 packages, one per API:
   libservlet3.1-java, libjsp2.3-java, libel3.0-java and
   libwebsocket1.1-java. libservlet3.1-java would depend on the three
   other packages to preserve the compatibility and avoid updating
   all the packages depending on the JSP/EL APIs.

3. libservlet3.0-java is similarly split into: libservlet3.0-java,
   libjsp2.2-java, libel2.2-java

4. Create new source packages to take over the API packages from
   src:tomcat7 and src:tomcat8:
   * servlet-3.0-api and servlet-3.1-api
     (built from https://github.com/javaee/servlet-spec)
   * jsp-2.2-api and jsp-2.3-api
     (built from https://github.com/javaee/javaee-jsp-api)
   * el-2.2-api and el-3.0-api
     (built from https://github.com/javaee/el-spec)
   * websocket-1.1-api
     (built from https://github.com/javaee/websocket-spec)

5. remove src:tomcat7, and later src:tomcat8 once src:tomcat9
   is available

What do you think?

Emmanuel Bourg

[1]
https://salsa.debian.org/java-team/libxmlrpc3-java/blob/master/debian/patches/02-servlet-api-compatibility.patch
[2]
https://salsa.debian.org/java-team/tiles/blob/master/debian/patches/01-servlet-3.1-compatibility.patch


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: