Rethinking the Servlet API packaging

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Rethinking the Servlet API packaging

Emmanuel Bourg-3
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



signature.asc (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Ioan Eugen Stan
Hello Emanual,

I agree the servlet-api should live/be built by their own packages.

>From a development point of view they are part of Java EE/Jakarta EE and
tomcat consumes them. 

Having multiple versions of the API in Debian also makes.

Regards,

Eugen

On 06.08.2018 13:47, Emmanuel Bourg wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Emmanuel Bourg-3
In reply to this post by Emmanuel Bourg-3
Le 06/08/2018 à 12:47, Emmanuel Bourg a écrit :

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

I forgot to mention the src:libservlet2.4-java package with the Servlet
2.4 and JSP 2.0 APIs.


> 4. Create new source packages to take over the API packages from
>    src:tomcat7 and src:tomcat8:

>    * 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)

The JSP 2.2 and 2.3 APIs are identical, and the EL 2.2 and 3.0 APIs too.
I think we could rather create a single package for each API: jsp-api,
el-api and websocket-api.

Emmanuel Bourg

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Markus Koschany-2
In reply to this post by Emmanuel Bourg-3
Hi!

Am 06.08.2018 um 12:47 schrieb Emmanuel Bourg:
> 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.

[...]

That is a very good idea. I also think that it makes sense to decouple
the Servlet API from src:tomcat{7,8,9}

[...]

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

+1

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

+1

> * 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?
As long as we don't have to change reverse-dependencies and everything
is just a drop-in, I think it's good. I can start packaging
libservlet4.0-java (I would name source and binary package the same). Is
it this one?

https://github.com/javaee/servlet-spec/releases/tag/4.0.1

Regards,

Markus



signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Emmanuel Bourg-3
Le 11/08/2018 à 09:19, Markus Koschany a écrit :

> That is a very good idea. I also think that it makes sense to decouple
> the Servlet API from src:tomcat{7,8,9}
>
> +1
>
> +1

Thank you for the feedback!


> As long as we don't have to change reverse-dependencies and everything
> is just a drop-in, I think it's good.

Yes that's the plan, i.e. the standalone libservlet3.1-java will depend
on the JSP/EL/WebSocket packages so we don't have to change the reverse
dependencies. But libservlet4.0-java won't depend on them anymore.


> I can start packaging
> libservlet4.0-java (I would name source and binary package the same). Is
> it this one?
>
> https://github.com/javaee/servlet-spec/releases/tag/4.0.1

Yes that's this one, thank you for jumping in but I've already prepared
the package. No package needs the Servlet API 4.0 yet, even Spring
Framework which is rather cutting edge still uses the version 3.1 in its
latest releases. So there is no hurry to upload it.

As for the source package name I'm not decided yet. Either keep the
historical libservletX-java scheme which was already used for the
versions 2.2 and 2.4, or use servlet-api-X which is more in line with
the recent Java EE packages uploaded (jaxb-api, cdi-api, jaxws-api,
jaxrs-api, etc).

Alternatively, we may even try to go with a versionless name
(servlet-api), and spin-off a versionned packages only if required due
to substantial incompatibilities introduced in the new releases.

For example, src:servlet-api would build libservlet-api-java/4.0-1, if
the Servlet API 4.1 is source compatible with the version 4.0, we just
upgrade the package. If later the version 4.2 breaks too many things we
create a package with the version 4.1 and we keep upgrading the
versionless package.

(Just some thoughts for discussion, I have no preference)

Emmanuel Bourg

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Thorsten Glaser-6
On Sun, 12 Aug 2018, Emmanuel Bourg wrote:

> (servlet-api), and spin-off a versionned packages only if required due

Either way (versioned or not), wouldn’t

        libservlet-api-java

be a less conflicting, more in line with the common
practice at Debian, package name? (Consider Perl stuff.)

Just my 2¢,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*************************************************

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*************************************************

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Servlet API packaging

Markus Koschany-2
In reply to this post by Emmanuel Bourg-3

Am 12.08.2018 um 00:52 schrieb Emmanuel Bourg:
[...]

>> I can start packaging
>> libservlet4.0-java (I would name source and binary package the same). Is
>> it this one?
>>
>> https://github.com/javaee/servlet-spec/releases/tag/4.0.1
>
> Yes that's this one, thank you for jumping in but I've already prepared
> the package. No package needs the Servlet API 4.0 yet, even Spring
> Framework which is rather cutting edge still uses the version 3.1 in its
> latest releases. So there is no hurry to upload it.
Even better. I need the Servlet API 4.0 for upgrading undertow to the
2.x version though. Undertow is not the most important Java package
these days but it would still be nice to upgrade it.

> As for the source package name I'm not decided yet. Either keep the
> historical libservletX-java scheme which was already used for the
> versions 2.2 and 2.4, or use servlet-api-X which is more in line with
> the recent Java EE packages uploaded (jaxb-api, cdi-api, jaxws-api,
> jaxrs-api, etc).

I am more in favor of using our standard scheme and append -java to the
package, just for avoiding namespace pollution. Servlet sounds a bit
generic to me, although it is a term I associate with the Java world. We
could keep the historical scheme in this case to avoid any confusion.
servlet-api-java would also work for me.

> Alternatively, we may even try to go with a versionless name
> (servlet-api), and spin-off a versionned packages only if required due
> to substantial incompatibilities introduced in the new releases.
>
> For example, src:servlet-api would build libservlet-api-java/4.0-1, if
> the Servlet API 4.1 is source compatible with the version 4.0, we just
> upgrade the package. If later the version 4.2 breaks too many things we
> create a package with the version 4.1 and we keep upgrading the
> versionless package.
>
> (Just some thoughts for discussion, I have no preference)
Yes, the introduction of a versionless libservlet-api-java binary
package could simplify transitions in the future. For those packages who
continue to build fine after an upgrade to 4.2 no further changes would
be required. For the rest we could change the build-dependency back to
libservlet4.1-java as you said. I would create an empty
libservlet-api-java package and depend on the latest version of the
Servlet API in Debian.

Markus


signature.asc (981 bytes) Download Attachment