[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


// 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: