Hello Arnaud, Friday, August 15, 2003, 11:46:31 PM, you wrote: > Jan Schulz <[EMAIL PROTECTED]> wrote: >> IMO the big enchancement is, that you only have to specify the >> Depends once: in debian/control and everything else is added from >> there on. > That's what we all want ;)
Ok, I take that as an agrrement and will add that to my upcoming proposal :) I will also try to implement the buildtime debhelper dh_java (is that name already taken?`) >> With my method, you don't have to either of this (if dh_ant will >> work as I would like it :) > Yes, I think it's the sort of code there will be in something like > dh_java (but I'll first test Stefan's code ;)). Yes, I will also test (and probably switch to it after I have understood the mechnism) CDBS, but having a dh_java, which does the actual job is IMO fine as well. CDBS can then make use of it. The advantage about a complete CDBS based solution would be, that someone not using CDBS still has a way to do it... >> Yes: they implement the same interfaces/classes. So whatever comes >> first will win. eclipse itself figures ot the 'Window System' to use >> with a param at startup time (default is compiled in). I use the >> 'jars' file to provide this bit as well. > They maybe have good reasons... I don't know how I'd do that but I think > it's a strange way of implementing this. But well, it's difficult. The system is quite nice: you have a xml file, which declares all the feature your 'plugin' has and 'extention points' where others can add features to your plugin. eclipse is one small core and the rest is extention to extention points. In this xml you also declare which jars holds the implemnting classes and the 'PluginClassLoader' automgically only has this jar and the declared dependencies on its classpath. In eclipse 3.0, all the IDE independend features are factored out, so that one can build a apps with UI (non UI are already possible), based on this mechanism. > Well it's a very difficult question because the classpath and > j2(sdk|re)1.4 have the jaxp api merge in the core api. The upcoming > kaffe 1.1.1 will also have it. But J2sdk1.3 and earlier versions did not > have jaxp. So if you look at libgnujaxp-java which is an implementation > of jaxp, and if you look at libxerces?-java, you'll have these > javax.xml.* packages and also org.xml.sax.* and org.w3c.dom.*. Maybe it is possible to add a package which: * Depends: on all this newly introduced API packages * Depends: on a special version of 1.3 JRE * Provides: JRE-1.4 * sets the alternative symlinks > All these > classes MUST be the same... but Sun's javax.xml... and gnu javax.xml do > not have the same license's terms! ? I thought javax.xml is a JCP thingie? How did they manage to relicense it? And how diffrently did they relicense it? From free to DFSG unfree? [eclipse] > Well, it seems to be a very very difficult package! I'm learning every time I put my hands on it :) > Well, Jan, I think that anyone who would maintain eclipse would orphan > all his other packages! :-D I'm thinking of packaging some more eclipse plugins. It should be fairly easy to do it, as almost every plugin is build via a eclipse buildin machnism, which is available as ant-script. > As everyone could read to night, Ean will soon upload a new kaffe > release, I suggest you have a try to build eclipse and run it with kaffe > and submit as many bugs as you can ;) I will do that, at the next time my time permits :) First will probably go to the eclipse BTS thouigh, as eclipse currently only accepts 'java|java.exe|javaw.exe' as 'debug target' (JVM, which runs my developed programm and whichc an be used to debug it). The RH eclipse ML has already a patch for accepting gcj... Have a nice week, I will go on holiday from tomorrow on :) Jan