On Sun, 10 Aug 2003 20:10:45 +0200 Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Arnaud, Hallo Jan, > * Arnaud Vandyck wrote: > > Can you give me some more explanations (private or on the list). > Here we go... I think you are on the list, so no private reply. Yes I'm on the list and told you that you can write the mail on the list _or_ private, so it does not matter. I prefer the mail on the list so everyone can participate because I think we absolutly need something to simplify the use of java in Debian. > >> * 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. > Currently the 'work' to figure out the classpath is on the > applications side: The autor of the startscript will have to set the > classpath according to the 'well documented classpath' (java > policy). This essential means, that you have to read every > README.Debian of every package, you depend on *and* of every package, > this package depends on... With this script, you put much of the work > to the person, who knows the classpath best: the maintainer of the > library package. $ apt-cache show <package> | grep Depends and then $ dpkg -L <package> | grep jar and you'll have all the jars for a package. Note that maybe you do not need all the jars from a package. 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. > Another pro is, that you can depend on different implementations of a > specific java API and the reason why I came up with such a thing > in eclipse. Applications, which have a UI based on SWT need to set > the classpath either to the gtk *or* the motif version of swt.jar. The > problem with this is, that the gtk 'swt.jar' is seperated into two > parts: the actuall swt implementation and the JNI glue (license > issue...). I could be possible, that the next version will have three > jars. Motif on the other hand has all its java code in one jar. > -> update-alternative can't handle this AFAIK. I do not know how eclipse works but do the jars conflicts each others? 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. > With the proposed solution, it would be the 'description' file, which > would be under u-a (it is in the case of libswt*). Same could happen > for xerces-compatible xml parsers. 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! > Packages, which depends only on a version of swt, can depend on > libswt2.1-java and get the classpath from the u-a managed value. > > 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! ;) > >> ** update_javaclasspath.sh [...] > Currently, using java, isn't really as easy as everything else in > debian is. The first thing is getting a JVM: go to sun, DL and what > now? Then you want java browser plugins working: mozilla is gcc 3.2 > and java isn't (or the reverse...) Yes, I agree. But I don't know why we all do not focus on getting a free JDK?! There seems to be a real interest of RedHat in Java. They are patching 'classpath' project, helping 'kaffe', making 'gcj', etc. I think it's a good idea to package java apps and libs for Debian and to search the better way having a decent complete java environment, but I think we have to focus the more we can helping 'classpath', 'classpathx', 'kaffe', 'gcj', 'sablevm', 'jikes', and so... 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. > 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! ;) > For specific versions, such a script should include params to get only > 1.4 compatible versions (or other...). It would also be nice, if we > would have virtual packages, which are more specific than > 'java2-runtime' or 'java2-compiler'. Or having the free JDK reach 1.4 specs. > Same goes for the java browser plugin, which should get a 'c102', when > compiled with gcc3.2 and be seperated out by mpkg-j2sdk. I agree. We also need to focus on having a good free java plugin. > Together with policy changes, this would help to make using java > software as easy as everything else under debian. ... with a complete free 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 Cheers, -- Arnaud Vandyck http://alioth.debian.org/users/arnaud-guest/ http://alioth.debian.org/developer/diary.php?diary_user=2781
pgp00000.pgp
Description: PGP signature
