Hello Arnaud, Thursday, August 14, 2003, 3:33:46 PM, you wrote: >> >> * Jan Schulz wrote: >> >> ** getclasspath.sh >> >> This script will be used in any java applications startscript. You (or >> a dh_java) put the dependencies (package names) as param and it will >> give you the complete classpath based on the Depends. > When you package an application, I think you have to know what jars are > needed by your application, then where to find the jar? you have > apt-cache search, dpkg -L, dpkg -S and so to find it.
Usually you need to know what version of what lib you need. If that version is packages, you add this package name to your Depends: dh_java (or yourself, if thats not oncluded in such a script) will then add this name to your startscript and the getClassapth script will set the proper jar files. Or so my theory. 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. > $ apt-cache show <package> | grep Depends > and then > $ dpkg -L <package> | grep jar > and you'll have all the jars for a package. With my method, you don't have to either of this (if dh_ant will work as I would like it :) > Note that maybe you do not > need all the jars from a package. If thats possible, then the lib package should seperate the jars. > libxalan2-java depends on libxerces2-java but you do not need > xml-apis.jar AND xmlParserAPIs.jar in your classpath. It's up to the > maintainer of the application to know what to do. This will anyway have to change with the inclusion of a 1.4 JRE: I think XML APIs are part of the JRE now, isn't it? > I do not know how eclipse works but do the jars conflicts each others? 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. > If you put all the jars in the classpath, eclipse won't start? I don't > have eclipse on this machine but I'll try. eclipse doesn't need any classpath apart from a jar to start it. The rest is done with URLClassloader and a xml registry, where you can register plugins, classes and so on. It expects the jars in subdirs of the main eclips einstallation. In this case the point is, that there hopefully will be some apps, which use SWT as their base and then they need to have a way to get all jars. > Not xerces-compatible, but jaxp-compliant, there _is_ a problem with > this. There are several jar files with org.xml.sax.*, org.w3c.dom.* and > jaxp.xml.* packages and they MUST be the same! ? You mean the XML API? I haven't really had a look at this, but this sounds, that the XML API JAR could be seperated from the implementation... >> For the 'contrib' use: ant currently uses a complete dir for its >> 'tasks'. There are other apps, which use such plugin like mechanism. >> For every such app, you need another dir. With the 'contrib' >> mechanism, you only let the plugins 'contribute_to' the application >> package. All such application then should ask for the 'conributed' >> classpath as well. > I don't know, but you are packaging a monster! ;) ? I only packaged eclipse so far (and got a good head start from my sponsor :). I got this idea from a build time script for GTK, which I use. It works similar to my aproach: you call it with the name of a gtk lib and it will return a string, which can be used with gcc, which includes compiler switches and all includes: gcc `something gtk2++` ... > Yes, I agree. But I don't know why we all do not focus on getting a free > JDK?! To speak of me: because it requires a lot of knowledge of ARCH dependens, C code and much more. What make the nonfree JDKs much better that gcj (not compile to native) is, that they have a Just In Time compiler (I have to admit, that I haven't had a try with kaffe or sableVM). Without such a thing, IMO eclipse won't be useable. gcj is just able to compile to native or run the app in interpreter mode. I think I can do some packaging work (I hope I'm able to package some more java apps in some time, but eclipse takes quite some time from a beginner...), but I can't do some serious c hacking :/ > think we have to focus the more we can helping 'classpath', > 'classpathx', 'kaffe', 'gcj', 'sablevm', 'jikes', and so... The only help I can give in that direction is to do the packaging. And making it as easy to switch between different JDKs or using java programms with it. And thats why I'm here on this ML and proposing this... > It's just an idea, I know we all have too much work to do everything. > But I really do not like to have Debian (free software, DFSG, etc.) and > use non-free JDK!.. I think we have to make things change. Partially I agree. I must admit, that I like DFSG software much more that propritary, but my first choice is still that 'which works'. I'm using opera as my webbrowser because it's the browser, which works best with me. The beta prozess is sometimes a PITA and bugreporting at bugs.mozila.org is probably much easier and you can see the results imediatelly. But still browsing with mozilla and without all the features of opera (I'm used to) is a even bigger PITA. The same goes for JDKs. When I'm back home, I will try kaffe1.1 to run eclipse and I will make all the changes it needs in eclipse, *if* it is possible, but I'm not as good to hack deep down in either eclipse or kaffe. And if kaffe is not as fast as one of the nonfree JDKs I will switch back for my work. I can't see the point in having to use a piece of software, which is free, but doesn't do the job. As long as I'm not able to do something about it (i.e. hack it until it fits my needs or help upstream to do this), I will use the nonfree (if I'm able to, which is the case with JDKs). >> This could be helped, when we have this helper scripts (install with >> mkpg-j2sdk, get the java.bin from a generic mechnism, which know about >> all so installed jdk/jre). > This could be a good thing but I cannot understand and figure how to do > that ;) You'll think I'm dumb! ;) I think the java.bin thingie works nicely with newly introduced virtual packages and update alternatives for /usr/bin/java-1.x. I will write a proposal when I'm home^W at my study place again and also try to contact the mpkg-j2sdk autor for this (I would like to get all this scripts into java-common or j-c to depend on it). > Or having the free JDK reach 1.4 specs. If a free JDK is mature enought to set a alternative to one of the /usr/bin/java-* I'm just as happy... >> Together with policy changes, this would help to make using java >> software as easy as everything else under debian. > ... with a complete free JDK ;) Until thats possible, I settle for 'with any JDK'. >> Another thing is then to write a compile time infrastructure, like >> * using ant in the same way as make -> dh_ant dh_make template >> * compute the Depends: lines or at least make this easier (like >> specify it once and use everywhere...) -> dh_java > I am also investigating 'maven'. I'll give you more informations later Sounds great, but I fear, that it's much more work in the long run to convert ant based things to maven than to write dh_ant. Or did I miss something? Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
