Hello,

I've started packaging a few (some very old) java packages required for vnu
and its dependencies.

xp + servlet api 2.2 -> jigsaw -> css-validator -> validator.nu

Questions:

=== [servlet api 2.2] src:jakarta-servletapi-2.2 ? ===

The only sources I have found that support servlet API 2.2 is the one shipped in tomcat3 [1]. At that time, the produced jar war labelled "servlet.jar"
Given that in the meantime there haven been newer versions of that API and multiple servlet-api jars in the archive (especially servlet-api-3.1.jar, servlet-api.jar, jakarta-servlet-api.jar...):
- what name should I use for the source package? I'm using "src:jakarta- servletapi-2.2" for now.
- what name should I use for the binary package? I'm using "bin:libjakarta-servletapi-2.2-java" for now. But maybe libservlet-api-2.2- java would be better?
- what filename should I use for the jar? Although default name is servlet.api, I renamed it to "jakarta-servletapi-2.2-servlet.jar" for now
which then becomes suffixed by version. But I wonder if I shouldn't use servlet-api-2.2.jar (without link to servlet-api.jar) or just servlet.jar.
- should it also be made availabe through maven repo like the artifacts at [2] ? It seems it was requested in [3]. In that case, how does one do this for a non 'maven-ized' package?

[1] https://archive.apache.org/dist/tomcat/tomcat-3/src/
[2] https://mvnrepository.com/artifact/javax.servlet/servlet-api/2.2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902530

=== |jigsaw] src:jigsaw ===

Package produces 3 jars. One of them is used in other packages (and published on maven), others are internal (and not on maven). Should I have 1 binary package for each like this (or just put all 3 in the 1st one like I'm doing presently)?

- libjigsaw-java (/usr/share/java/jigsaw.jar)
- jigsaw-jigadmin-java (/usr/share/jigsaw/classes/jigadmin.jar or rename to jigsaw-jigadmin.jar)
- jigsaw-jigedit-java (/usr/share/jigsaw/classes/jigedit.jar or rename to jigsaw-jigedit.jar ?)

At the moment I ship all 3 in bin:jigsaw-java and install to
/usr/share/jigsaw/classes/jigsaw.jar
/usr/share/jigsaw/classes/jigadmin.jar
/usr/share/jigsaw/classes/jigedit.jar

The other binary packages would be:
- bin:jigsaw (the main package)
- bin:jigsaw-doc (the javadoc for libjigsaw-java)
- bin:jigsaw-jni (contain native libary)

As per the server configuration files (the "Jigsaw" dir of orig.tar), I wonder if it is worth to install them. I have no interest in them because I only need the jar (which contains required classes) and I don't know if someone would really want to run this old and unmaintained (no update since 2007) http
server on Debian nowadays. Presently I'm installing them (to /usr/share/ jigsaw/Jigsaw), but leave the configuration and the final steps of
installation to the user. I see two alternatives:
1. Just ship the preconfigured "Jigsaw/" dir in a compressed form to /usr/ share/jigsaw/Jigsaw.tar.xz and let the user manage it themself and suggest unpacking it to their desired location be it /var/lib/jigsaw, /srv/jigsaw and setup the server on that base.
2. Ship the preconfigured "Jigsaw/" dir uncompressed in bin:jigsaw-[server-] example under /usr/share/jigsaw/[server-]example. The user can then make a copy, and remove the example package.
What are your thoughts?

=== [css-validator] src:css-validator ===

Upstram permits to build jar and war.

It can be invoked by command line, and is also a webapp (usable in jigsaw, but also tomcat9/jetty9 (support for the **javax.servlet** package/api is required).

For the **jar**, given that on the one hand it is an application, and on the other hand that it is used as a dependency for vnu, should it go to /usr/ share/java/css-validator.jar or to /usr/share/css-validator/css-validator.jar (which is my present choice)? Shipped in bin:libcss-validator-java or bin:css- validator (present choice)?

How would you ship the **war** or **webapp**? At the moment I'm doing like this:
- bin:css-validator-war (/usr/share/css-validator/css-validator.war, having an empty WEB-INF/lib)
- bin:css-validator-webapp (war extracted into /usr/share/css-validator/css- validator/, where I have symbolic links to the jar deps in /usr/share/css- validator/css-validator/WEB-INF/lib). The user then has to add that dir to tomcat(9) which will dereference the link, or copy the content by
dereferencing the links to jetty(9). Both approaches work.

URLs to the repositories:

https://salsa.debian.org/bastif/xp https://salsa.debian.org/bastif/jakarta-servletapi-2.2 https://salsa.debian.org/bastif/jigsaw https://salsa.debian.org/bastif/css-validator

Please keep me in copy of your reply since I'm not subscribed to the list.

Regards
Fab

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/06/2025 07:40, Fab Stz wrote:

Questions:

=== [servlet api 2.2] src:jakarta-servletapi-2.2 ? ===

You most certainly don't need the Servlet API 2.2, the package should
build against libservlet-api-java (Servlet API 4.0) with minor
adjustments (if any).

=== |jigsaw] src:jigsaw ===

Package produces 3 jars. One of them is used in other packages (and published on maven), others are internal (and not on maven). Should I have 1 binary package for each like this (or just put all 3 in the 1st one like I'm doing presently)?

If jigadmin and jigedit aren't necessary, don't package them. Also don't
bother packaging the javadoc.

=== [css-validator] src:css-validator ===

Upstream permits to build jar and war.

It can be invoked by command line, and is also a webapp (usable in jigsaw, but
also tomcat9/jetty9 (support for the **javax.servlet** package/api is required).

For the **jar**, given that on the one hand it is an application, and on the other hand that it is used as a dependency for vnu, should it go to /usr/ share/java/css-validator.jar or to /usr/share/css-validator/css-validator.jar (which is my present choice)? Shipped in bin:libcss-validator-java or bin:css-
validator (present choice)?

Typical packaging for a command line tool that can be used as a library:
- bin:libfoo-java contains the jar in /usr/share/java (and maybe the
Maven artifacts in /usr/share/maven-repo)
- bin:foo depends on libfoo-java and a Java runtime, contains scripts
and related files in /usr/share/foo

How would you ship the **war** or **webapp**?

If vnu doesn't require the webapp, do not package it. Let's keep things
simple (and fun).

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/06/2025 20:32, Fab Stz wrote:

You most certainly don't need the Servlet API 2.2, the package should
build against libservlet-api-java (Servlet API 4.0) with minor
adjustments (if any).

Actually I did that initially and even tried to "fix it" but that went much above my skills and interest. Enough to prefer engaging in making the package for api 2.2 and searching its source code (which was not an easy part). Actually many functions of servlet >= 2.3 are not implemented in jigsaw. Build
fails with any servlet-api version >= 2.3. Would anyone try to fix/patch it? The package on my salsa repo would be a good starting point since it builds fine with the bin:libjakarta-servletapi-2.2-java package installed, otherwise
sources (without the debian part) can taken from: https://github.com/tenzap/jigsaw (branch with-jdk21).

I just realized that Jigsaw is actually a web server, so that's not
surprising if it doesn't build with the Servlet API 4.0.

But this raises another question: why a 20 year old unmaintained web
server is necessary? Is it possible to do without it?

How would you ship the **war** or **webapp**?

If vnu doesn't require the webapp, do not package it. Let's keep things
simple (and fun).

Now that it's done, can I leave it that way instead of just throwing all the work away?
It can actually have some interest to deploy the war/webapp on the server (jetty/tomcat) that's why I packaged it.

It's also about avoiding extra work in the future for maintaining a
package that may not be used.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/06/2025 07:33, Fab Stz wrote:

But this raises another question: why a 20 year old unmaintained web
server is necessary? Is it possible to do without it?

I don't know exactly. Digging into the internals of jigsaw to know why would be too time-consuming. I have 2 guesses:
- css-validator can be installed into tomcat but also jigsaw (see https:// jigsaw.w3.org/css-validator/DOWNLOAD.html )
- css-validator requires package "org.w3c.www.http" (~60 classes) and some of its dependencies that are shipped in jigsaw.

I got a look and I confirm it's possible to build css-validator without
jigsaw, by just importing a few classes:

https://github.com/w3c/css-validator/pull/449

It's also about avoiding extra work in the future for maintaining a
package that may not be used.

I find it useful to ship also the webapp. Without it, we only have the command
line interface and I don't know if it is feature-equivalent. All the html files of the webapp are not shipped otherwise. We could also drop the package in future if it is source of problems or maintenance burden?

But why would one want to install a CSS validation service when there is already one hosted by the W3C? I see the value in the command line tool,
but not much in the web service. But if you are ready to maintain it in
the next 10 years, why not.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/06/2025 16:27, Fab Stz wrote:

I got a look and I confirm it's possible to build css-validator without
jigsaw, by just importing a few classes:

https://github.com/w3c/css-validator/pull/449

Ok, thank you for that. Can I use it directly as a patch in the Debian package, or should I rather use the "d/missing-sources"?

A patch is fine, with a reference to the PR.

In this case, this would make my question of the original e-mail relevant again. It's the last paragraph starting with "How would you ship the **war** or **webapp**?..."

A webapp is more convenient, ideally integrated with the jetty or tomcat packages (something like the solr-tomcat or solr-jetty packages we used
to ship [1]).

Emmanuel Bourg


[1] https://packages.debian.org/buster/solr-tomcat

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)