Re: Classpath and versioned libraries for Debian-Java
On 0, Ola Lundqvist <opal@debian.org> wrote:
> I'm a bit curious. In what way is the java extension mechanism useless?
The extension mechanism is only there to solve one problem: setting classpath. It does not care about all the other stuff I mentioned. What should I write in my Applet's Manifest file - xerces.jar, expat.jar, crimson.jar, or what?
> I have a question to you all. Should we allow the same interface in
> different packages? It seems to create strange conflicts but sometime it
> is necessary, or? What do you all think?
That's also one thing I was thinking about. If we say we don't include DOM and SAX in Xerces, it's more clean IMHO, but much more work when packaging. We can't just call 'ant jar' to create the .JAR files, we have to create them ourselves. I think it's ok to have Xerces include DOM, although it's not the Best(tm) way.
> Do you think the above description is covered in the proposed policy. It should
> be but I'm not sure if it is clear enough.
Well, I think it's not fully covered, but it's possible with your proposed policy. It's not about replacing the policy, the policy is good, it's about adding to the policy.
> > - library F and library G may both provide the sub-library H, of the same
> > version - they may both be installed, but not in the same classpath at the
> > same time.
>
> If they completely provide H, why can't they be in the same classpath? One
> of them will override the other. Or am I wrong here?
Yes and no.
I most cases, e.g. the DOM interface classes, that's ok. They won't conflict because they're identical.
But look at the TRAX API, the TRAX classes included in Xalan call concrete Xalan classes in the TRAX factory classes (it has to, somehow). Another XSLT processor will call their own concrete classes in the TRAX. So TRAX of Xalan conflicts with TRAX of [fill in any other TRAX-implementing XSLT processor here]. The same with javax.xml in XML parsers. That's what I meant here.
>
> > - much more complicated stuff I've forgotten to mention here
>
> True. Everyone that can find such a problem, please try to describe it
> so we can deal with that too. :)
Maybe we should create a checklist?
> I think the debian control file is easier to parse using simple tools. Other
> people can convince me that I'm wrong. :)
On the one hand, XML would be cool because we can demonstrate Java's abilities, and all helper applications like dh_java could be written in Java. On the other hand, you're right. Hm, I don't know yet what I'm for.
> We will have some kind of jar dependency mechanism very similar to the
> "normal" one, right? This does not cover installation dependencies but
> run-time dependencies...
Yes. Debian's package dependencies are similar, but not similar enough to create classpaths from it.
> The jar dependency information file should only adress direct dependencies,
> right?
Yes. Indirect dependencies are calculated by generate_classpath.
Regards,
Max
P.S. Ola, have you received my mail this week (maybe my local mail setup is broken again..)? I've finished Xalan 2.1 packages, downloadable at ftp://ftp.leanedit.org/ola/
Reply to: