Re: Large-scale java policy violations
On Mon, Sep 17, 2001 at 11:51:10PM +0200, Stefan Gybas wrote:
> Ola Lundqvist wrote:
>
> > Yes it bothers me too. What bothers me more is that someone (I
> > do not remember who) told me that I should name my package
> > libxalan2-java instead of lib-xalan2-java.
>
>
> This was probably me. I had a long discussion with Stephane Bortzmeyer
> (original author of the Java policy) about this, but I don't remember if
> it was on this list or in private mails.
>
> Anyway, the initial idea behind lib-XXX-java was to use the Java package
> name, e.g. org.w3c.dom would be in a Debian package called
> lib-org.w3c.dom-java. However, more and more Java software with classes
> in different Java packages was released, so this was not suitable any
> longer.
Ahh. I see. Now I understand the old lib-foo-java naming, thanks.
> I then decided for my packages to use libXXX-java for libraries where
> XXX is the name of the product/project, e.g. libxerces-java. Real
> applications, i.e. not just JARs, like Tomcat were just named after
> the project. These also depended on java-virtual-machine instead of just
> java-common in the case of Java libraries.
>
> About the version: I'm not sure if it makes sense to include the version
> in the package name. It might be appropriate in some cases, e.g. I'm
> thinking about packaging Xerces 2.0 as libxerces2-java so Xerces 1.x and
> 2.x can both be installed at the same time, but I don't see what we could
> gain from libxerces1.3.1-java, libxerces1.4.1-java, ...
Well that was my thought too. With vervion I ment part of the
version that are interesting. Like libxalan2 or libxerces2. Not
libxalan2.0.x, just as you said. But this should be more clear when
I update the policy.
> A different story is the naming of JARs inside the package. It might make
> sense to include the version there, so instead of
> /usr/share/java/xerces.jar I could use /usr/share/java/xerces-1.4.1.jar
> and create a symlink or using alternatives. But then some suggestions
> like automatically including all jars in /usr/share/java to the default
> classpath cause duplicate and conflicting classes.
>
> Summary: I'm for using libXXX-java instead of lib-XXX-java (and with the
> exception ofg libpgjava I'm already doing this) and I thing the version
> number should be allowed in the package but not enforced. So we end up
> with library packages named lib<projectname>[<version>]-java. Packages
> containing applications (i.e. shell startup scripts in /usr/bin) should
> just be named after the application without -java appended.
Exactly what I have in mind, only with a better specification. :)
> If everybody agrees to this scheme, I'll rename libpgjava (which was
> created before there has even been a discussion about a Java policy) to
> libpostgresql-java.
I agree with this.
Regards,
// Ola
> --
> Stefan Gybas
>
>
> --
> To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: