On Fri, Nov 09, 2001 at 11:46:53AM +0100, Max Kellermann wrote: I'm sorry. I think I forgot to mail to the list. Thanks for getting the thread back on the list. :)
> On 0, Ola Lundqvist <[EMAIL PROTECTED]> 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 think so yes. I have not tested it though. Maybe it solves that issue, and maybe not. Anyway this is a java2 thing so we have to make a wrapper (or similar mechanism) for java1. > > 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. I did never ment any replacing. I just curious if this was clear enough ot not. Apperently not. I'll try to figure out how to make this clear enough. :) > > > - 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. Then it actually does not provide it right? It provides something else just very similar. > > > - 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? That is a good thing, yes. > > 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. True. > > The jar dependency information file should only adress direct dependencies, > > right? > > Yes. Indirect dependencies are calculated by generate_classpath. Good. > 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/ Yes I got it. I'll see if I have enough time to look at it today. I do now see that I forgot to answer your mail, sorry. Regards, // Ola > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 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 / ---------------------------------------------------------------
msg00890/pgp00000.pgp
Description: PGP signature
