Path: csiph.com!news.mixmin.net!weretis.net!feeder8.news.weretis.net!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Fab Stz Newsgroups: linux.debian.maint.java Subject: Packaging questions for css-validator (& webapp/war), servlet-api 2.2... Date: Mon, 16 Jun 2025 08:00:01 +0200 Message-ID: References: X-Original-To: debian-java@lists.debian.org X-Mailbox-Line: From debian-java-request@lists.debian.org Mon Jun 16 05:57:10 2025 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.196 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .yahoo. - helo: .sonic306-19.consmr.mail.ir2.yahoo. - helo-domain: .yahoo.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Sonic-Dkim-Sign: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750052406; bh=tZz5VJXEmyYacPs+d4+CfxtqlVCgZ06rnOCILEocOyv=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=a5SRTtntQJe02vFOq1Z0/TPqeH/fPG5sCf1Z8oACIVe52JmDl28evxgVAZ7R1LcDYEV6mktTLh5UMEid8tCV5fsyvVhVfdDcMN8eiEKNTzjZGU3aHccva0QIMy9Ol6CcSEfnGYYUPxtL1GapOFmF2gpQndZw5vwvmfNsopJ+rYnaaJJw9rFdc7Vy1y3xzhnJDHkhG+q9U6FQKEGfJAgCoGBaU7541RNEdz+eG6pygU+Wu3BhZ+5R7Sn2YOf+QQZA1Uyg0HmpBMirfHq1I6gYP+IGjnexnxa9tO6KK5ZeK1PrvVfYLzcnbEe19Q0LnhP9fnMrvQ0wjDZ1NT8YVorDHg== X-Ymail-Osg: y.Ny734VM1lglUKShsYkUVhA2yfZRhKeHreUrBvxaSXRTK31OImLoRhJq7bl1bk E5xrB9lJElN_zjDQuh9beCaGPEJRdT1uKOOsHpgyMDY86S0H8Pis7DHPGXTabfTjXh0UkVPgeYsW 8Dl9hn0F_83LZvkM0mKcxdrEJWdJBX.xQAuur6GU99j3kEXEGlNvpqvhzch5o23fFY3LPdszTvil xR3onUV53_ppEgqHbYx3qLlAcW6YNyuwMQA7dL_1lXQvuNUPF2bavObelYzBDInH1uAGnpXc0_yY ageqX9IK6qCuRoLqTMQTAzACv.J3BKdErOOukkeiYG48JWlWRp5DHpxOdtx7Syw7b74kNocBzIxR 1XF6B5P5ZNWPzTrr9Wo2UVQWRPVeVgxL3KJhI_qDSdxXque8wWnAC3optm.GqUlfLMYNxvn5.S1p HrxV0TdFul9JJFJGRz9W07XRJnMRCdNGHgmdBvNjAu367lU7CTDbu89hoGYDgj51d2RpDySc5ZlQ rWuAceAOuFLzPB.GiG05d1Fctar4vOBSeQQ7aD10d3WeP.OEPuBIpz8dX7vKlJIMjs2SkoG58YzW sqw0ueyH9GmdwI0IXuI5grfmGxZlsomnMgoAwuYCrKr_AvbVG7JUSXJ5ABEJv9fZW0_AXt14e6hK WWqZMffMZrC7b8TpnUPja_rT399WAp.6K4DgIckuHVCWpO1Jdy733TjjX1o0qzjbvIw4I28PDuwC W_0RkWgJtA1W9nXrJJuSfF6R5Rqk3Si5VRF.N91GhuWZQNGcJ7mV1GeA0ok67lgO9wmX9U_ZRBN7 fv.c_1V7zeX9qQeNBuSRpFCuEuLrBSlD0.4hcFIL8.WH.4sjzFz7rBcrmV0ROC2aXAioUkHBVJrV yy_t9RRfQm0gkTpnCjA63GLGHvtsyCmUtiK0dfxyJFrY7wuI2oKxfAb7aO42CXFS1xsJkWKU_kgf RqTm32J.FOcBiNz70QnAbXtWXYGzPjMU16o9d2v1MWnKAgRW3Qrl3P9vXFHtu_N3NwnrSxzNWrXk PbxogwCFlOViTXbEXFjuwO5h0Hdtu3sYzKHh1KhOl5864curVN7BM4B7YpKxObl3qqusnuWo7AHU 9aD1c4diOaQEBTE.S7GrPJ95aQDQC6XV8V8uan1DSfNM3uJWumnGBVUXad4mTn7xCO92c356fEvc 1LjpUZ17z6SPrQEpC5Z6l1h5ewlz11udfEQHWF3Dp9dibFIws8VMQ9ry2Xy3WUfsJ3U62TY0zv0Q tMXNgWILjRDTMKZiypKZkpdSdRs03wQzNHGKiRb9b.vnIIdDnz3c.ApoiswueA1ehcc0uIUY3T.M yNRMfRN3hJLL7lqZ0qs32zUPKO7dgJHXfg9svOy0bhPxT0EVDDZov8IyEFxTYdUhla4YcUGNPS6A 6fjXmWrvQyJz26UlkylsoAARvtX9E2_vYfWrhSm2P34sEy6YmHokp2nthhFbv4BYeCoClIL0TM5m QMuTmGxOhMcqa1lx7e1R8.bC1UeoBdXl2b3ZXR3.MKeCtaSgbOvcq3cOIK85rNzfTXAMhdrE7Q4A NNddBgC95.I2_ITN2rm4hQt149lQP9Dn9XMtvc_tsnwsH3pj8poKNM1AyRYZDZOi4IH7UG0D3bGI MwCHvHPptGchMANYhJTsIMF3fZcV5GTg4VRjovAcirRP39SBxWVSIXFIz9aQUac8HllnN7.DWm03 x8x2K2fOczJcynkrsBLIbUJyzDr2mxgRkqlqK4iW7_ACDlslxekk.XbOt7m_aRxTTOX8GBtSyjhS fBS7u5rLVXWJ1x45FjrnA6d2imYQdhQpLqxsz1xW1wC2Sbsq26L_BTPultgrIUn4NQo4eHyvekmz wPDQC6N0dY4gZNHMWu3Qe.8VtkpYnpm3Rz8LQ4YWUjf9Wl3habsZiNRI4foKZXrYCbIdcKVU5Gd4 7C2y1Wcmh1CEza9e5QdmMHFBsRzHM6PBuAeZDC1oyTVcxxavKgZHJ81uIwxlaAU31aNVu1j1WcE. MYvqeamnXHCNSS_Hq_svUT9jaKe0qrdi.ul.eoeTpdVp0aXP9bzc7Y..kPpadT59VRLcLItmjuiH xKyLHwbaT7j7yZkECIYL1YOeFsQgN69gofAWzUuEy6MEcc4Pm1kFfJ.uOH.QFH0b9yBH0B2LwsyD PBZLTKqmryh.Ams7pfzA2DKPeLuHGEW78W8bTma9HnbNLIXij5ah5i2LsD1HYTQcT6Qb27fspBwE G7RTx_hBjaOINp.YZtN9H1DIbjPtbExhNbPxzIqrEfrhjt5JNqLDg0d1LFix1Jl5DBBjLAWNVDic W X-Sonic-Mf: X-Sonic-ID: c8fecbb4-073a-4084-9307-7d4baad71173 MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mailer: WebService/1.1.24021 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Mailing-List: archive/latest/23734 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/3223984.Mh6RI2rZIc@debian Approved: robomod@news.nic.it Lines: 107 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Mon, 16 Jun 2025 07:40:02 +0200 X-Original-Message-ID: <3223984.Mh6RI2rZIc@debian> X-Original-References: <3223984.Mh6RI2rZIc.ref@debian> Xref: csiph.com linux.debian.maint.java:13008 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