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
