Re: Packaging questions for css-validator (& webapp/war), servlet-api 2.2...

Emmanuel Bourg <[email protected]> Mon, 16 Jun 2025 14:55:33 +0200
Newsgroups gmane.linux.debian.devel.java
Message-ID <[email protected]>
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