Re: Java policy draft
Hi You, Sanghyeon Seo wrote: I just finished reading http://wiki.debian.org/Java/Draft Me too. :-) Some comments: [Virtual packages] Please define, what it means to provide a virtual package. From the context of the document, the only *garantee* this provides makes is you can develop java programms with this or you might be able to run some java programms with this. This means they can't be taken for package dependencies. To be usefull, I would expect something like Classpath-sdk: /usr/bin/javac alternative with commandline compatible with... /usr/bin/javah alternative with ... The same should go for each alternative, as otherwise scripts might break. This is the same as the sh alternative: /usr/bin/sh only garantees the sh interface, not bash. But you can read, what's behind this garantees in the man pages or POSIX. IMO, its ok to leave the different sun derived java out of the policy, as most of packaged stuff will work anyway and something like a tomcat is anyway not touched by this document. But make it easy to replace the classpath based JREs/JDKs with sun derived ones. [Java libs] quote Some package must also provide a symbolic link from packagename-extraname.jar to the most compatible version of the available packagename-extraname-version.jar files. /quote I couldn't find a use case for this. For arch any, this is provided by the -dev package. It should not be used for symlinking aka linking (eclipse,etc), as it means that a wrong version can end up in the place. It also means, that you need alternatives for this (think two different version needed by tomcat and eclipse). I'm not sure whats the gain for building packages. In my experince, you anyway have to link in the jars by hand at build time, so it isn't so different to link in something-1.3.jar or something.jar. [Plugins] Plugins are not covert in this document, but are real common. Maybe it would make sense to add a chapter on this how to package them (Naming, etc) [JVM finder and CLASSPATh builder] IMO it would make great sense to add a jpackage like CLASSPATH builder and JVM finder and add the experience with this to the java policy. Up to now, the java policy is mostly about packaging, but not about how Nice greetings, Jan (participant of the 2003 discussion about Java policy...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt and java
Hallo Arnaud, * Arnaud Vandyck wrote: 3. Azareus - not in main, contrib, or non-free. If you have some time, you can contact Shaun Jackman [EMAIL PROTECTED] and help: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215127 And resolve the problem, that it is GPLed, but requires a GPL incompatible lib (swt)... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: What's the plan for Eclipse 3?
Hallo David,
* David Goodenough wrote:
I seem to recall that there were thought to be problems with some of the
directory structure that Debian packaging for Eclipse 2 was using, but I have
heard nothing recently.
No there are not, as far as I can tell. My fist shot was to package
eclipse3 to /usr/{share,lib}/eclipse3/, so it can be installed next to
eclipse2. The only problems are with the new additional sites in
/usr/local, as eclipse still relies on the eclipse/{plugins,features}/
layout of this additional sites. I'm not sure whether this has changed
with the latest changes to the update manager API
I have now orphaned the package, so its up to somebody to pick it up. I
will be around on ths ML for a while, if there are any questions.
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
Bug#276096: O: eclipse -- Extensible Tool Platform and Java IDE
Package: wnpp Severity: normal Hello, I have no longer time to maintain this package. Eclipse2.1 is outdated and should be replaced by version 3.0. Early work on this is on www.katzien.de/debian/eclipse3/. It works, but it needs a lot of polishing... There are also new libswt3 packages in a different source package See this mail for more information on the state of the packaging: http://lists.debian.org/debian-java/2004/09/msg00039.html Package information: Package: eclipse-platform Source: eclipse Version: 2.1.3-3 Priority: optional Section: contrib/devel Maintainer: Jan Schulz [EMAIL PROTECTED] Depends: j2re1.4 | j2re1.3 | java2-runtime, libswt2.1-gtk2-java | libswt2.1-java, liblucene-java (= 1.2), liblucene-java-doc (= 1.2), libeclipse-jni (= 2.1.3-3) Suggests: eclipse-nls-sdk (= 2.0.2-3), mozilla-browser | x-www-browser Conflicts: eclipse-xerces, eclipse-nls-sdk (= 2.0.2-2), libswt-java, libswt2.1-gtk2-java ( 2.1.3-0), libswt2.1-motif-java ( 2.1.3-0) Architecture: all Filename: .//eclipse-platform_2.1.3-3_all.deb Size: 25741550 Installed-Size: 33276 MD5sum: fa26a6a8f7fc539695e9891e7ed47c75 Description: Eclipse platform without plug-ins to develop any language The Eclipse Platform is an open and extensible platform for anything and yet nothing in particular. It provides a foundation for constructing and running integrated software-development tools. The Eclipse Platform allows tool builders to independently develop tools that integrate with other people's tools so seamlessly you can't tell where one tool ends and another starts. . This package provides only the Eclipse Platform. It doesn't include any development plug-ins. These are available in different packages: . * eclipse-jdt Java Development Tools * eclipse-pde Plug-in Development Tools . This package is the base for all eclipse plug-ins. . You need a SUN derived Java virtual machine to run eclipse. Either use a Blackdown mirror or build your own packages via j2se-package (both not in the official debian archives). Package: eclipse-jdt Priority: optional Section: contrib/devel Installed-Size: 15006 Maintainer: Jan Schulz [EMAIL PROTECTED] Architecture: all Source: eclipse Version: 2.1.3-4 Depends: eclipse-platform (= 2.1.3), eclipse-javac (= 2.1.3), junit Recommends: j2sdk1.3 | j2sdk1.4 Filename: pool/contrib/e/eclipse/eclipse-jdt_2.1.3-4_all.deb Size: 11719380 MD5sum: 9fd26b09bea125b6122147e618144c22 Description: Java Development Tools plug-ins for Eclipse Eclipse JDT plug-ins to develop Java applications with Eclipse. . JDT provides a whole Java IDE, complete with Java editor, debugger, Ant and JUnit integration and much more. Package: eclipse-sdk Source: eclipse Version: 2.1.3-3 Priority: optional Section: contrib/devel Maintainer: Jan Schulz [EMAIL PROTECTED] Depends: eclipse-jdt (= 2.1.1), eclipse-pde (= 2.1.1) Conflicts: eclipse Replaces: eclipse Architecture: all Filename: .//eclipse-sdk_2.1.3-3_all.deb Size: 16826 Installed-Size: 56 MD5sum: 45568bfea19d8b1954ca6865d9cfa181 Description: Extensible Tool Platform and Java IDE Package to provide the whole Eclipse SDK, which includes the Java Development Tools and Plug-in Development Tools. . This package is equivalent to the SDK drops you can download at eclipse.org. Goodbye, Jan
Orphaning eclipse packages (asking here first)
with verison numbers in the strings. . Droped eclipse-nls package, as it is too outdated. Wait for a new version to be released. . Bump all version numbers: s/2.1/3.0/g and append version numbers to the package names, so that they can be installed next to the 2.1 ones. This is also nessesary for the Rich Client Platform and other packages, which might follow. . drop a few replaces and conflicts, which shouldn't be nessesary anymore as the files have different names. . drop backport build dependencies. Sarge is about to be released and it is too hard to figure out the dependencies. Send a patch, if you want that added again. . droped java 1.3 in the eclipse packages: it's not supported anymore. libswt still depends on java2-runtime. . eclipse3.0-java does not anymore contain any plugins, only the things needed to call /usr/bin/jdtc3.0 and the ant compiler adapter * Changes to the package build prozess: . Uses cdbs for everything and not the helper scripts... = completly redone the rules file... . ant.properties includes a hack not to zip the result of the build prozess, so that we take everything from tmp and put it into the right place. Should speed up the build prozess... . The debian/rules file is a complete mess, as I had to work around some really stupid native build problems. To make it short: upstream hasn't added a way to compile them. So I had to do it... . Both the motif and the gtk starter binary are build now and put into the eclipse3.0-jni package. Dependencies are only Suggests:, as one of the window system is pulled in via the eclipse-window-system Depends: anyway. . Some debhelper files are now autogenerated via debian/input/ * Droped all patches, including the debian only ones. No idea yet, how to port them to new system and if thats needed. Some parts are now supported upstream, just in a different way. * Cleaned up various debian/* files . copyright: add 2004 * Just a note: the motif libs do not compile with lesstif. So no main... -- Jan Schulz [EMAIL PROTECTED] Thu, 12 Aug 2004 04:03:10 +0200 So, if anyone would like to step up, here is a nice packages waiting for you! To get you a easier way in: have a look at the clean target and the debhelper.in rules. cdbs knowledge won't hurt either, as there are a few hacks in the package to work around cdbs shortcomings. I'm around on both ML and available via ICQ: 149216469. I will help as much as I can do! I will file a formal orphaning bug, if noone on this ML wants to have it. Eclipse should be removed from the archive once eclipse3.0 is in. Nice greetings from Karlsruhe, Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: Orphaning eclipse packages (asking here first)
Hallo Laszlo, * Laszlo 'GCS' Boszormenyi wrote: Anyway, a group of people may be better than one maintaining it. Yes, thats true! Just looking into it; well, your rules should use a tab character before # Lets install next to the old version instead of spaces. Arg, that was on of the last changes before uplaoding. I wanted to do some more comemnts, so it's more readable. i really should switch to ecmacs for coding... few hacks in the package to work around cdbs shortcomings. Was the original rules so complicated? cdbs may tie you in several things when you have to be flexible for such a big application. The original rules file wasn't so complex, but was split into several places, as I used bash scripts o handle compiling and such things. So the overall build sequence was even more a complex. If you delte the swt rules, it gets better, but I didn'T want to delete them as thy might be usefull for someone. Nice greetings, Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: java-gnome vs. SWT
Hallo Mark, * Mark Wielaard wrote: Since SWT is distributed under the CPL, Common Public License, which is not GPL compatible, you won't be able to distribute a larger work based on it under the GPL. What is with GPL+linking exception? Azaurus (sp?) is also GPL and absed on swt and tehre is already a ITP for it. I haven't tried java-gnome on Wine or cygwin. Best to ask on one of the java-gnome mailinglists about that: Thats where swt comes in handy: it runs under win and OSX too. Jan
First gcj package in the archive
Hello, The first gcj based package is in the archive: http://packages.qa.debian.org/s/swt-gtk.html http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=swt-gtk And already there are some problems: * If ther are jni parts, the jni files need to be in LD_LIBRARY_PATH. No idea if thatc an be worked around by using rpath in the build prozess. * The name of the package should IMO be libsomething-gcj I have no idea what to do with this, but I feel that we should work on a policy for this packages, otherwise we will have a mess (like the above package is, at least from my point of view as a eclipse maintainer). Nice greetings, Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: Eclipse 3.0 packages for debian not yet ready
Hallo Jerry, * Jerry Haltom wrote: I'm curious if you have had any ideas about packing Eclipse up so that the integrated feature finder can function. There is apparently a way to alter the path that downloaded plug-ins are downloaded into. Haven't investigated it much though. I haven't looked at that, but I suspect, that this can be worked around with additionall plugin locations (sites). Anyway, all features, which are installd by the package manager will be patched to disable the internal update-manager. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
[Java Policy] no dependencies on real java versions
#239309: can't find working java on install when JAVA_HOME not set reassign 239309 java-common #228532: No upgrade when sablevm is alternatvie for /usr/bin/java reassign 228532 java-common thanks Hello, I'm reassigning this two bugs from eclipse to the real cause of the problem: The java policy. IMO this bugs are grave, but I don't want to add then to the list of RC bugs of sarge... The problem is, that we don't have a virtual package system which can figure out the proper dependencies and the policy mandated /usr/bin/java link is too weak (could be JVM 1.1.8, samblevm or a full featured SUN derived 1.4). For discussion and ideas how to solve this problem, see http://java.debian.net/index.php/CommonJavaPackaging Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: Troubles with Eclipse
Hello Yevgen, Wednesday, April 14, 2004, 12:56:17 PM, you wrote: Unbound classpath container: 'org.eclipse.jdt.launching.JRE_CONTAINER'. I am using the newest version (2.1.2) from sid under Blackdown Java 1.4.2-rc1. Any ideas? No, but I will get some after you send the excpetions which can be found in workspace/.metadata/.log. There is also a new version of eclipse, availabel as source from my repository - http://www.katzien.de/debian/eclipse Unfortunatelly UI broke the source.gz on the last upload, so you need to download by hand. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Building completly from source (was: Debian Bugs information: logs for Bug#221236)
Hello Arnaud, Monday, April 12, 2004, 3:42:57 PM, you wrote: I planed to ask some clarifications of the debian java policy about a 'build from sources' but I don't think it's necessary. I plan to file RC bugs on java packages not building from sources (that's why I'm Cc'ing to debian-java). Can you tell me which package does not build from sources? eclipse for a starter... Please wait with doing this until after the sarge release and after the new policy. I have no problem with this action, but I would like to deal with it in one go and not one after each other. As for eclipse: * The version of tomcat isn't in debian anymore, so we would need to package a old version and upload it, just to get eclipse working. * The ant version is ok after the next release. Unfortunatelly they use the complete ant, not only libant, so Stefan would need to package the optional jars 'Api like' (installable in different versions). * The xerces version of eclipse isn't packaged yet. They use a IBM maintainance stream, which is somehow not compatible anought with the normal jakarta xerces. So in short: I would like to get eclipse into sarge (if tahts still possible...) and it won't happen when you file RC bugs about this issues. It's in contrib, so Ifeel confortable with this issues being present in sarge. YMMV. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Ant editor in eclipse
Hello Arnaud, Thursday, April 8, 2004, 12:01:56 PM, you wrote: You mean 2.1.2-2 or 2.1.3-2? can you please also update your Sources.gz file ;-) Oh no, don't tell me the source.gz is still pointing to 2.1.2-2? If so, I've uplaoded 2.1.3-2 just yesterday... complains are false ones IMO (Why can't I have a *symlink* in /usr/lib if the package is Arch: all?). Arch-Indep cannot go to /usr/lib! Something that is Arch-Indep must go to /usr/share. It's a symlink to a arch dependendend file in /usr/lib/jni. Anyway, I will remove the symlink as is not nessesary anymore with teh new package layout. But not before I'm back at my study place, so it will take until a week after Easter. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Ant editor in eclipse
Hallo Arnaud, * Arnaud Vandyck wrote: Done. But Jan, before asking for a sponsor, please, take the advises more seriously! I told you about the two or three problems I got building eclipse on powerpc (FTBFS). And when I did download eclipse, it did exactly the same thing! You did not change anything from my recommendations. I've been obliged to download eclipse on a x86, building it and then re-download the result to sign it and upload it! Sorry that this went so bad. For the problem with the SAXException I can do a workaround, but the real fix must come in the ant package. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240245 For the other bugs you reported (s/i386/powerpc/): I can't see that being a problem. It sould not be the source of any build problem. Changing it without changing it on other places (including java source code) will break eclipse and the easier solution is simple keeping 'i386' on all linux platforms. AFAIR I sent a mail to you to add '-v' to the ant calls to get more verbose output to see the real problem. I'm preparing a new eclipse version, which supports setting a debug flag, so that ant produces verbose output. This version will also have the workaround for the ant problem. I will drop you mail and I hope you are still willing to do some testing then. The upload will be done until tomorrow morning. By the way, Eclipse MUST be available on powerpc and ATM, it's not in Debian! I feel the same, but unfortunatelly I don't have a powerpc arround to test the build. I don't even have a 1.3 JDK anymore, as the sun one doesn't work here anymore :( Sorry again for the bad communications and my neglection to fix this bugs. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Ant editor in eclipse
Hallo Arnaud, * Arnaud Vandyck wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240245 1° you can version the dependency by using libant1.5-java maybe; 2° or we are stuck and I can not upload the package :( 1° won't help without changing the build system to CDBS or doing Copypaste from this classes. For now I build-depend on ant 1.6 and add the jars. It's a workaround, but what the hell... Stefan, please fix it... :) We'll discuss this later... I don't have the time to investigate right now but Jan, be sure that I want to help, but I've not the time ATM. I've just uploaded a -2 version, which contians the above workaround and you can now set DEB_BUILD_OPTIONS=debug and ant will print verbose output. I hope that will help to locate the bug. Please send me the build_java.log (the others are renamed to the new name when the build was successfull, so no need to send them. They will be *huge*...) The only other change was the removal of a lintian complain about the old kde desktop dir, which is now empty after removing the kde desktop entry. No need for two desktop entries... The rest of the lintian complains are false ones IMO (Why can't I have a *symlink* in /usr/lib if the package is Arch: all?). java version 1.4.1 Oh, I didn't know that. Once I heard that there is no 1.4 JDK for PPC. Ok, good old big blue :) So why aren't they publishing eclipse for tis platform? Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Ant editor in eclipse
Hallo Hein, * Hein Meling wrote: Anyone else have this problem? Is there a known solution? I could not find anything on google. known (have a look in BTS of eclipse) and fixed, but not yet uploaded, due to no sponsor. The source of this bug is the ant 1.5 - 1.6 switch, which changed the jar names and split the optional jar. deb-src http://www.katzien.de/debian/eclipse ./ apt-get source -b eclipse-sdk BTW: I'm still looking for a sponsort for this release! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Ant editor in eclipse
Hallo Arnaud, * Arnaud Vandyck wrote: BTW: I'm still looking for a sponsort for this release! I'll try to upload and build it tomorrow... Thanks a lot! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: eclipse 2.1.3-1
Hallo Arnaud, * Arnaud Vandyck wrote: 1° xml problem with ant has been resolved by adding the relevant libraries in debian/bin/build-java.sh as you told me. Add this line at the beginning of the script. export CLASSPATH=/usr/share/java/jaxp-1.2.jar:/usr/share/java/xercesImpl.jar I think that is a ant bug and Stephan said he will change that behaviour. As a sidenote: This would be solved by the discussed scripts for a new java policy... 2° but when building for powerpc, I have to add this line: OS_WS=-Dos=linux -Dws=gtk -Darch=powerpc in debian/bin/build-java.sh This is wrong. All arch are compiled with a x86 string. I know it looks stupid, but this system is used in eclipse to make 'unzip a drop over another drop' possible. There are three places, where this value is used. * The launcher, which sets the value at runtime * the classlaoder, which loads native library from a subdir called 'x86'. * At buildtime such a dir is created. So you could actually chnage that to 'debian' and it wouldn'T change anything. It just has to be consistent in all places. I haven'T had a look into each part of the code and I don't want to do it just to get a different value there. So, to sum it up: I don't think that this is the problem. :) Please drop me a mail with the stacktrace of ant. Please add a '-v' to the ant call. Ther is another isue: The latest package can be used to compile arch depended code only, so you need not to compile the java code. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: eclipse 2.1.3-1
Hello, It seems like tora, my regular sponsor for eclipse, vanished :( If you happen to be here tora, please speak up! If someone would be so good to upload the eclipse packages to unstable, I would be really happy. They currently are not going into testing due to different problms, on of them being that there is a outdated version of eclipse 2.1-5 lying around on the mirrors. I really like to get eclipse into sarge... avdyk is curently trying to build them under PPC, but I also need packages for i386. avdyk curently has got a problem with XML based packages while building, which I think is some problem with ant 1.6, but I couldn't get my hands on the real problem yet. So I would be really thankfull, if someone could upload a i386 version to unstable. You need to upload the changes for both the 2.1.2-2 and 2.1.3-1 release, as none of them were uploaded to unstable yet. Something along this lines should get that done: dpkg-buildpackage -rfakeroot -B -v2.1.2-1 -kyourKeyID Miss the '-B' if you are doing the first upload :) I would prefer a i386 upload first, build with a 1.4 sun derived JDK. But that's up to you :) As the 2.1.3-1 package have some bigger changes in the package structure (see my mail to debian-java), I would also like to get some more testing. It works fine here, but I may have overlooked something. The complete changelog since the last uploaded version to unstable: eclipse (2.1.3-1) unstable; urgency=low * New Upstream version: Again, only bugfixes, no new features * Remove patches integrated upstream. . new-cvs-response.patch . org.eclipse.ui.workbench.texteditor.patch . 00-PDE_build_with_NLS.patch * Updated eclipse-javac links for ant. * Removed ant dependencies and include the jars from upstream. This is due to the problem, that debians ant is now 1.6, but eclipse requires 1.5 ant. As the 3.0 version changes this anyway, I didn't bother to patch this: this is too much work and too less result (xerces and tomcat are also taken from upstream source). * Introduced 3 new packages: lib*-jni, which includes all native compiled parts from the corresponding Java packages. (closes: #232882) . Conflict and replace older versions to force them off the system . Compile this parts in it's own target, so that arch binary only releases are a lot faster. (closes: #232852) * Add some info to the libswt*.README.Debian re compiling the jars to native libs with gcj. (closes: #232011) * Removed one desktop file, as this is not anymore needed since kde 3.2 * Sidenote: kaffe is now able to do rudimentary startup. -- Jan Schulz [EMAIL PROTECTED] Wed, 24 Mar 2004 17:28:29 +0100 eclipse (2.1.2-2) unstable; urgency=low * Added a note to NEWS, that the install can fail, if sablevm ends up being the only JVM for eclipses config app. Also added some note to the postinst scripts. This is a bug in the java policy, as I cannot exclude sablevm from the /usr/bin/java alternative, which the postinst uses as the last option. Workaround is to set JAVA_HOME to a working JVM before doing the upgrade. * Tighter dependencies between packages, so that upgrades will work. (closes: #229587) * Added patch to work around problems with latest cvs. (closes: #231135) * Make /usr/bin/eclipse -nl aware and use LANG to determine the to be used language. To change that independly from your normal settings, add LANG=... to your $HOME/.eclipse/eclipserc (closes: #231464) * Tried to remove as much whitespace changes from the 'addsite' patch as possible. * Removed the '#!/bin/bash' from startup function: its not meant to be executed, only sourced. * Added my name to the copyright. * Added debian package version to version string, which is shown in Help|About * Readme.Debian: s/artikel/article/g. Thanks to David N. Welton for spotting it. -- Jan Schulz [EMAIL PROTECTED] Fri, 6 Feb 2004 21:35:36 +0100 The package is available as source from deb-src http://www.katzien.de/debian/eclipse ./ - apt-get source eclipse-sdk Thanks a lot for your help! I really hope that I can get this version into testing... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
splitting jni libs into it's own package
Hello, Whats the best way to split JNI libs into it's own package? I have three arch dependend packages, which contain some small jni libs and a binary starter. They are now part of the java packages, which need them. This means that I need to compile all parts (slow, I can't split the compile into parts...) and then package a small arch dependend lib with each java package (bloats the archive). To give some numbers: libswt*java: around 1 MB, half of it is arch dependend Eclipse-platform: 25MB, 20KB arch dependend Build Time HD space: 400MB+ Build Time: 20min on my system Buidl time for only the arch dependend parts: a lot less space and time. I'm now trying to get this sorted out and came up with three different versions: Spliting each package into two packages libswt*-java + libswt*-jni eclipse-platform + libeclipse-jni Pro: . means that I can have clear dependencies (wrt to GUI Toolkits) from each package. . Fast to compile (arch dep parts) . cleanest solution Con: . Small *-jni package libeclipse-jni (less than 50k content, three files). No idea, if that will be accepted. The rest will be around 300k content. Putting all jni parts into one libeclipse-jni package Pro: . fast to compile (arch dep parts) . one jni package, about 800k content, 9 files . easiest Con: . No clear dependencies wrt GUI Toolkits: swt motif will pull in gtk dependecies Only splitting eclipse-platform Pro: . One small jni package (see above), but not anymore 20+MB Arch: any package. . clear dependencies wrt to GUI toolkits Con: . No time speedup with arch dep Any ideas? This all sucks, as this is a release, which I didn't expect to make, but I hope to get it into testing. Actually I wanted to make this step in the 3.0 packages, but they will take some time longer, as the build script generator, which comes with eclipse isn't up to date wrt the latest changes in eclipse. So I need to package this 2.1.x maintainance release... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Arnaud Vandyck] Bug#99337: RFP: jdk-installer -- debian installer for SUN's java2 (v1.3)
Hallo Arnaud, * Arnaud Vandyck wrote: I think it's the third time I send this mail on the list... anyone have a comment? Hm, first time I have seen it... |I don't know the status of mkpkg-java (or mpkg-j2se) but I think it |solve this RFP. Yes, IMO some DD should get in touch with the author and ask him if he wants to see and maintain his package in debian unstable and if he agrees start uploading it as his sponsor. Otherwise we have to find a different way (alioth?) to get it into debian. I really think we should get this package into sarge and into the 'official answer to how to install a SUN derived JDK. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian package for sun's j2sdk
Hallo Heretik, * Heretik wrote: I've read in the FAQ that a debian installer for sun's jdk1.4 is to be made so i'd like to help doing it. # java unfree stuff... deb http://nosid.de/z42 debian/ deb-src http://nosid.de/z42 debian/ - j2se-package I really hope that this package gets uploaded to unstable in time for sarge.. And someon who has write access to the debian java FAQ should update the entry... So if i can help doing this, please tell me how i could start. I think some of the sun derived JDKs (IBM) are still lacking the backend for j2se-package. If you are intersted in them... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Signal 11 running Eclipse
Hallo Aurélien, * Aurélien Labrosse wrote: at java.util.zip.Inflater.end(Native Method) Known and reported. See the BTS for the workarounds. I really don't know, how I can make #228599: [SUN derived JVM] crash in zip related code any clearer... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java in main for ofbiz
Hallo Arnaud, * Arnaud Vandyck wrote: Would be cool to have JBoss in Debian ;-) NTW: JPackage has packaged JBoss, so why not have a look there :) Its kind of fun, as well, as it is interesting, what kind of features other packages have. So far I've found 4 different eclipse packages: JPackage, gentoo, RedHat (gcj, native) and a FreeBSD port. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libxalan-java
Hallo Stefan, * Stefan Gybas wrote: Xalan and Xerces don't not have external APIs themselves. The API for Xalan is TrAX and packaged in libjaxp1.2-java. If some packages are using internal classes directly (like Xalan does with Xerces), they are basically on their own. It's like applications that might break when they are using internal libc6 references. Ok, so I misunderstood, what the libxalan-java package is about. On the other hand, I don't understand things like that then: apt-cache show fop: [...] Depends: java-common, j2re1.3 | j2re1.4 | java2-runtime, libxerces-java, libxalan2-java, libbsf-java ( 20010106-2), liblogkit-java, libavalon-framework-java (= 4.1.2-2), libbatik-java (= 1.5final) It seems that some packages use xalan directly and having it upgrading to a newer breaking API version will break this apps. Therfore I think it would make some sense to treat this packages 'as API' as long as we have software, which uses internal API. I have no idea, how fop uses xalan, but if it is like 'call the app', then libxalan-java should probably become 'xalan' anyway. Another 'IMO': Everything with lib in front should be 'library packaged'. Otherwise it wouldn't be 'lib' (I know that this isn't true with some normal packages, but... :) Jan, only opinions... -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libxalan-java
Hallo Arnaud, * Arnaud Vandyck wrote: Jan Schulz [EMAIL PROTECTED] writes: I agree, but with you should read the arguments of Stefan: I'd like to name the new source package in main libxalan-java ^^ Moep... Sorry, for all the inconvinience. I completly missed the 'source' here. Lessons learned: Never read a ML when you are learning for an exam... Jan, pulls down the brown bag... -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libxalan-java
Hallo Stefan, * Stefan Gybas wrote: I'd like to name the new source package in main libxalan-java (instead of libxalan_2_-java) since that's also the name that upstream uses. IMO that as bas as using kdelibs instead of kdelibs4 Jars like xalan are libraries and should be packaged accordingly. Thats also the reason, why the proposed policy uses 'nameAPI_Version[-extra_Name].jar' and 'libnameAPI_Version-java' as names for jars and packages. Just consider, what will happen if the next xalan version includes breaking API changes. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo David, * David Walluck wrote: $ build-classpath jdbc-stdext ant bsh xerces-j2 [...] You can see how jdbc is a jvm extension so it exists as a symlink is /usr/lib/jvm-exports. Every other jar (normal jar) gets picked up in /usr/share/java a bit easier. Hm, seems that the only real difference is, that in your case the JVM will pickup some jars because they ar ein a special dir and in my case, it wll be picked up because -bootclasspath is used. One other difference is, that I propose to add had dependecies (package manager level) and your scritp does it automagically, when jars are installed, right? Seems that we aren't far away at all! If I promise to build in all your functionality (JVM including, CLASSPATH ordering for ant) into a script, do you think we can agree on doing it all at runtime? And putting in a way to enforce JVM depedencies which can configured to work around (and use a non packaged JVM)? JPackage? Gentoo? Debian? Any other? java-config should work like any other -config script I presume. [JPackage equivalent of function based idea] Yes. I would also like to consider your 'shell functions' based idea, but that would mean that every startscript needs to be #!/bin/sh, instead of using a generic script, which outputs a string. An idea would be to add a wrapper script, which just calls the functions in the right order and one 'function' script, which just includes the function and which can be sourced. Hey, cool. I'm seeing light on the end of the problem tunnel :) Seems that we were far nearer together than I expected. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo David, * David Walluck wrote: So if 1.5 is API compatible to 1.4, the the jar should still be name-1.4.jar (or at least a symlink :) But if 1.5.3 breaks something, it should get name-1.5.3.jar. But libraries have the concept of software version, and then totally apart from this is the library version used by, for example, libtool, and meant to distinguish API incompatiblities. I am not sure I'd want to mix the two. So in Java 1.5.3 is going to refer to the software version and not the API compatibility level, so I still think the jar should always be named with the full version. You're not going to get any libtool type versioning going with such a simple structure. You could attempt to make symlinks to every comptable version from 1.5.0 up to 1.5.3, but that just gets really messy. Hm, I would like to introduce that. Currently it is not possible to support different API versions (API defined libtool wise) on a debian system (AFAIK Jpackage also only support 'old' and the current version). libswt currently is designed to do, but breaks debian java policy. The current setup is like this: libswt2.1-[motif|gtk2]-java provides libswt2.1-java libswt2.1-java guarantees the there is a /usr/share/java-config/libswt2.1-java file, which has a line |JARS=/usr/share/java/swt2.1-motif.jar or |JARS=/usr/share/java/swt2.1-gtk2.jar:/usr/share/java/swt2.1-gtk2-pi.jar So when I have a app, which wants to use swt, it can use this line to figure out the classpath entry (that's basicly what findjava is for, in my proposal). If swt3.0 is out, I will add similar entries and if it breaks API compatibility to 2.1, I will have no problem, because all jars are versioned and can so be installed next to a different version. So IMO, versioned package name should go with versioned jars. Even if they are used through a script. The only garantee, which should be made is, that one package name contains jars with the same name as any former version of that (versioned!) package. This way you can symlink to it without a problem. And if API breaks, you have a new package and so everything stays fine. In some cases (when using a script to help over the issue), you could even split the jars, as long as the API stays backward compatible. eclipse.org has a nice article about designing and evolving stable API. I understand from a Debian perspective, you want to name your package libfoo1.5-1.5.3 and be done with it, but we have no guarantee of the API compatibility level. You never have until a) upstream documents it, or b) it breaks. In first case, you can do the change beforehand, in the second case, you need to do two uplaods, one with a source package of the older source package with a newer version number (epoch... :( ), so that the old API gets installed again unbreaking the system and uploading the new source with a new package name (and different source name). Thats at least the way I would handle it on debian. And the second case should be catched by some testing... In the both cases you would end with two source packages (named diffrently) and two packages, ones the old version and the new version. In Java, it *always* seems to be the case that it changes, even in *micro* releases, which is to say, that only libfoo1.5.3-1.5.3 may be sufficient for some software. Package, which need that are probably not fit to be called library... That's another thing, what libraries should be: have stable API. In this case it would be better to link statically - include the jar. [re-finding old rules for java] In short, just because you are I might be used to all of these things being second nature, they obviously aren't in the Java world, or we would even be here having this discussion, would we? :) So it's good that we have it :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo David,
* David Walluck wrote:
``Make specifying the build classpath easy using either command line
switches of property files (and document it).''
currently we use `export CLASSPATH', how does this fit in? Note that a
build.xml using only properties cannot easily be used with our
`build-classpath' script.
I think it means that you should NOT use hardcoded path, but expose
such path to the buildscripts options.
So instead of writing
javac ... classpath=c:\xerces.jar;... .../
write
property name=xerces.jar value=c:\xerces.jar/
[...]
javac ... classpath=${xerces.jar};... ... /
This way you can overwrite the xerces location without patching the
build file.
It would even be better to use a kind of ./configure to build a
properties file and pass that to ant. We could add that in the end of
our discussion, when we have agreed upon a common packaging way.
For #8:
We should add that all jars should have a manifest (but without
Class-Path). Ant can autogenerate a manifest, or does, I forget?
BTW: I never yet touched Manifests, what are they actually for? :)
For #9:
I'm not sure how this applies to most developers, or even developers of
tomcat for example, as they aren't going to have `ant install' use this
layout
The problem is, that upstream isn't aware of it. Currently eclipse has
to make use of a lot of symlinks. Just because it assumes, that native
libraries are in a subdirectory of eclipse, which is itself located in
/usr/share...
For #12:
The source code should be in a directory, not top-level like most zip
files (I can't stress this enough---I don't know how many times I
unzipped a pile of source code to my home directory).
signed! It also means taht it has to repackaged for debian, as debian
expects the source in a directory of its own.
The directory should have the same name as the archive, i.e.
name-version. Sometimes simply `name' is used, but it's not recommended.
signed. Also expected by dpkg.
Sometimes, it's typical for Java developers to put *binaries* in the
archive like this and append -src to the source archive. I don't
recommend this. Instead, maybe append -bin to the binary archive and
leave the -src archive as name-version.tar.gz.
Signed! Actually they shouldn't be any differnt than the normal
upstream source tarballs provided by any other language.
Similarly, we might go as far as to recommened that the jars produced
have versions in them.
IMO, they should go with the same strategy as the normal libaries:
Changing names only when a API changed.
So if 1.5 is API compatible to 1.4, the the jar should still be
name-1.4.jar (or at least a symlink :) But if 1.5.3 breaks something,
it should get name-1.5.3.jar.
This is alos part of teh proposed debian policy. Debian will rename
the jars in this manner, if that is accepted.
be verified. The md5 sum can tell me if the archive was damaged or not.
It cannot tell me if it's authentic. That's why md5+gpg is recommeneded.
signed!
Somehow I just relize, that we are putting up a list with points, but
just rewriting rules, which are in use in c or any other language
releases since ages :). I wonder if they had once the same problems :)
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo Jan, * Jan Schulz wrote: ``Make specifying the build classpath easy using either command line switches of property files (and document it).'' currently we use `export CLASSPATH', how does this fit in? Note that a build.xml using only properties cannot easily be used with our `build-classpath' script. I think it means that you should NOT use hardcoded path, but expose such path to the buildscripts options. And after reading it again, it should also mean, that you shouldn't use such a thing: --8-:- snip -:-8-:- snip -:-8-- [...] export CLASSPATH=$HOME/project/name1.jar:$HOME/project/name2.jar java -cp $CLASSPATH ... --8-:- snip -:-8-:- snip -:-8-- Instead use something like this: --8-:- snip -:-8-:- snip -:-8-- NAME1=$HOME/project/name1.jar NAME2=$HOME/project/name2.jar [ -r /etc/app.classpath ] source /etc/app.classpath export CLASSPATH=$NAME1:$NAME2 java -cp $CLASSPATH ... --8-:- snip -:-8-:- snip -:-8-- Or simple wait until we have sorted the issue out and use the agreed upon way. :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo Nicolas, * Nicolas Mailhot wrote: jsse.libs=$(build-classpath jsse) javamail.libs=$(build-classpath javamail) test.libs=$(build-classpath junit xerces-j2 httpunit) ^^^ I thought you don't have such a script. Thats exactly what I propose to use, but on runtime. And merging it with your static 'put all the symlinks in place' code and redoing it so that it outputs one line, which incldues all the information and can be used to start the JVM. So instead of doing symlinks and then start the JVM, you will do java-config --execute-line --jvms=JVMpackage1:JVMPackage2 \ --classpath=$ANT_PUT_FIRST;package1;package2 \ --jvm-options=server:256MB \ --add-lib-path=/some/other/path/you/asked/for/ which will output: /usr/bin/jvm \ -Djava.library.path=/usr/lib/jni;/some/other/path/you/asked/for/ \ -bootclasspath some added jars, specified by the JVM package... \ -cp the whole CP, as requested by the app and tailored to the JVM \ specific JVM options, to enable server, heap size and so on Add the main class and the options, and you're done :) $JAVA Main.class.Name Options This script could even do dependency checking upwards (lib has more restriction than app, so less JVM are taken in account) Some points I forgot but I agree with - care to add them to the writeup ? Will do after the discussion is over. Don't want to discuss in the wiki if we have such a nice ML :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo Nicolas, * Nicolas Mailhot wrote: face the same problems and wish for more or less the same things : [...] Would you mind adding that to the wiki? Seems like a nice thing to have there :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]
Hallo Nicolas, * Nicolas Mailhot wrote: I'm done with this. The result is available at: I'm rather proud of myself since I merged the full JPP document, my mail, added a few ideas and corrected (a bit) the result. That text is great! Thanks a lot for specifying the whole thing. Hoepfully some people upstream will take it and do something about the proeblem :) I will add a small para for debians 'don't use JAVA_HOME', but will label that debian only for now. Ah, and maybe another para about 'not using non-API classes' would be good. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227587: [PROPOSAL] Java library dependencies
Hallo Stefan, * Stefan Gybas wrote: I've read Jan's proposal yesterday (but not the following discussion with Dalibor and others, so I won't comment yet) Which version? The content changed quite havily with the discussion :) and I don't see how his proposal solves this problem. AFAICS his proposal simply removes the java*-runtime virtual package altogether. Yes, it does. They get replace with direct dependecies to the real packages. No, I push it to maintainers of Java applications which use the library. IMO this is a good thing until we can do the dependencies in a findjava script. This is not yet implemnted in the proposed policy and also not in the scripts. Also wrong. But since the latest sablevm package now provies java2-runtime, my whole proposal is superfluous: sablevm will be installed to satisfy the java2-runtime dependency if you don't already have Blackdown packages installed and applications like tomcat4 will simply not start. That's also a way to solve a problem... Even worse, even if BD packages are installed (And BTW, recent BD *packages* will probably crash on a recent sid. See the last mails in debian-java or my eclipse buglog :( ), as sablevm seems to set a very high u-a priority. This whole system is a mess! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java2-runtime, was Re: Bug#227587: [PROPOSAL] Java library dependencies
Hallo Stefan, * Stefan Gybas wrote: [Not CC'ing the bug since it's not related to it] Thought so, too, but was too lazy :) Jan Schulz wrote: Which version? The content changed quite havily with the discussion :) The original one. As I've said, I've not yet read the discussion yet. Hm, better go to the Proposal before the last one and start there. Most of the arguments are repeated there and it lead to teh final version, which IMO will work quite well. I'll send my comments in a couple of days so we can discuss all this at FOSDEM. You can als start adding comments to the CommonJavaPackaging page at the java.debian.net wiki. I hope we can do some more work on the whole issue and then do a policy proposal, which will also implemnted by gentoo and jpackage. The /usr/bin/java* alternatives don't matter since tomcat4 does not use them. BTW, is that actually a bug? My latest eclipse package will fail if sablevm is sinstalled and /usr/bin/java is set to to it *and* neither gij nor kaffe nor and JAVA_HOME is set. Just got the first bugreport. What a mess... I'm concerned that not all required packages are installed to run tomcat4 although all depencenies are satisfied. I have to remove java2-runtime and only depend on the known to work JVMs. I would like to do that as well, but recent BD packages, as I said before, will not run eclipse as well in some cicumstances. So I actually have no packaged JVM, which will run eclipse. Only j2se-package will do the trick with 1.4.2 JVMs. BTW: I think tomcat will run into the same problem... I fully agree with you! The only useful things in the current Java Policy are /usr/share/java for JARs, /usr/lib/jni and the naming of library packages. Everything else is based on wrong assumtions. :-( You summed the last version of the policy proposal nicely up: That's probably the only thing, which I kept from the old version. Although I have to say, that I changed the naming to libsomethingAPI-version-java and the jars to somethingAPI-version[-additional-Name].jar. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: eclipse crashes on startup
Hallo Thomas, * Thomas J. Zeeman wrote: First off: Juergen, thanks for the fast response! From me too! Finaly I can give something to my eclipse 'failed in native code' bugs. With both BD 1.4.2-rc1 and Sun 1.4.2_03 it gets aborted during compilation, an earlier point than where BD 1.4.1 crashes! [...] I used an 'export ANT_OPTS=-Xmx256M' as suggested by ant and it failed; with 512M too btw. Do note that when I first compiled my own .deb I never needed to set ANT_OPTS. The code in the compiler script uses 256 anyway. Here's the output to stdout: dpkg-buildpackage: source maintainer is Takashi Okamoto [EMAIL PROTECTED] No, it's me :) echo /usr/lib/j2sdk1.4-blackdown/ /usr/lib/j2sdk1.4-blackdown/ Seems ok... /usr/bin/ant: line 35: 10182 Killed $JAVACMD $ANT_OPTS -Dant.home=/usr/share/ant org.apache.tools.ant.Main $ANT_ARGS $@ Java Compilation Failed That looks like the vM got all og the availabe memory and got killed by the kernel :( I have tried doing a build of the original sources included in the deb-src but that also fails. It looks like I get a little further every time I restart that build without clearing the previous build first, but after 5 or so runs it still is not finished. Running top during the build shows 3 java-processes slowly eating up more memory and at about 128M the run stops. Running the build in 'valgrind --leak-check=yes' showed no sign of leaking. You may want to set $ANT_ARGS to somethiong like -v and/or -debug and try if that gets more output. I'm not sure what is happening on your system, but unfortunatelly ant will eat more memory than 128MB to compile eclipse. It seems that your kernel or anything else on the system wont let it take anything more than 128MB and ant gets killed at that time. It's AFAIR not the VM, which kills itself, this would show the OutOfMemeoryError and no 'Killed' line. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227587: [PROPOSAL] Java library dependencies
Hallo Stefan, Hi Ben, I'm just cutting in here... * Stefan Gybas wrote: Ben Burton wrote: You still have not answered my questions about JUnit: Which package do you want in Debian? A stripped version without Swing GUI in main or a full version in contrib? Which one do you want to ship with your custom projects? JUnit is free, even with the Swing GUI classes. In this case: Use a striped down one. I'm not sure, how far we can go with that. In teh new 'Common Packaging page', gentoo guys ask for Support of gentoos 'USE' Flag. I understood that as a way to remove/add functionality at builtime. I'm not sure, how far the free VMs are, but if that's enought to get them into main (- packages compile, but will not work. And yes, I'm not a debian-legal regular :) I've no idea, if that's 'free enough' ), we might consider using such a system in debian packages as well. In a normal build, use a empty USE flag and put a readme into the package, which add the information, what USE Flag to set to get the rest of the functionality with a sun-derived VM. And BTW: it would be nice, if you have a look at http://java.debian.net/index.php/CommonJavaPackaging, adding your thoughts as well. The problems you are discussing here are the exect topic, which should be solved with that page. My opinion to the rest: * j2/1-runtime does not garantee anything *at runtime*, so it is useless in that respect. IMO, and that was the result of the policy discusion [1], it should be replace by individual dependecies on each 'known working' JVM package and then used by a 'for java in list' code (which hopefully will be replace by a findjava script) This requirement is even more flawed, as the only thing, which is garanteed, but unfortunatelly by *both* virtual packages, is /usr/bin/java. You should know the result with using that alternative... * There is currently no way to enforce (as with dpkg [3] or any script[2]) library package dependecies 'upwards' (lib needs JVM_A and will not work with JVM_B. App chooses JVM_B), so IMO, the only thing what such dependencies add are information for the application packager, what JVM needs to be removed from the 'list'. Which would be much better in a README... [1] For the result, please see the bugreport at the java-common package or use deb http://www.katzien.de/debian/java ./ - new-java-policy [2] Unfortunatelly my scripts, as of now, also will not enforce such a thing. Suggestions welcome, please add your thought to http://java.debian.net/index.php/CommonJavaPackaging :) [3] And you would still need a script, which enforces it at runtime... So, I don't know how far away sarge is, but maybe instead of getting yourself flamed here, put up your commets at the above page and maybe we get that implemented earlier than the next Debian release :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227587: [PROPOSAL] Java library dependencies
Hallo Stefan, Do you want to be included in the reply? * Stefan Gybas wrote: I think you are making the same mistake as Ben here: java*-runtime just means the core classes, no JVM! If you need both, you need to depend on Hm, j-v-m us a even better exapmle for a policy redesign. Is there any exepmle, that a runtime from one JVM works with another? The only exemle I have ist using at compiletime to compile you package against a certain runtime. This requirement is even more flawed, as the only thing, which is garanteed, but unfortunatelly by *both* virtual packages, is /usr/bin/java. You should know the result with using that alternative... Wrong. This is guaranteed by java-virtual-machine, not java*-runtime! That doesn't makes it better. YOu have a package dependency, but then youa re using *one* entry place, which basicly has no dependency handling *at all* and does not interact with the requirements of your package *at all*. Both, j*-r and j-v-m are in my personal opinion completly useless. They don't give you anything, no dependecy handling, not garatees, that it works. Nothing. I don't want to put the burdon of testing all possible runtimes to library packagers. In most cases they can't do this even if some unit tests are included. Unfortunatelly yes :( See the FindingWorkingRuntime and ApplicationClasspath page son java.debian.net. This problem is adressed there somewhere. But basicly the choice is between either strict testing and dependencies and no failures on one side and less strict testing and dependecies but failures on the other side. Maybe we can agree on something in the middle... For example, I can now tell that libtomcat4-java and all its libraray dependencies work with Kaffe 1.1.3. This does not mean that tomcat4 uses all possible methods in these libraries. So IMHO it would be incorrect for the all of them to depends on kaffe | java2-runtime since that And BTW: what will happen if you add a webapp, which require some '1.4 and not implemented in kaffe' features? would imply that they fully work with Kaffe. That's why the application that uses these libraries needs to depend on the known to be working JVM(s) and runtime(s). ACK. And IMO, they should use both of these as 'one'. So, I don't know how far away sarge is, but maybe instead of getting yourself flamed here, put up your commets at the above page and maybe It's not flaming. It's just a discussion with some misunderstanding. ;-) I know :) I've had my share of them during the proposal discussion :) we get that implemented earlier than the next Debian release :) Don't be so pessimistic about Debian releases! :-) I don't mind, I'm running unstable+experimental now :) I hope to be able to read your proposal this weekend since you obviosuly have addressed some of the problems that I tried so solve. That would be great! Anyway, I will wait for the result of our 'common packaging' discussion on java.debian.net until I take further steps. It would be a great thing, if we (gentoo, JPackage, Debian) could agree on a certain set of policies and tools, so that java apckaging becomes a lot easier and also more dependend. And of course better for our users :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugwatcher problems
Hallo Mark, * Mark Howard wrote: Bugwatcher works with gij or blackdown java My wrapper scripts just call /usr/bin/java, since both of the above create this. This has two problems: - my programs don't work if java alternative is set to something else I noticed :) - it is not easy for me to ask users to test things with an alternative jvm if [ ! -N $JAVACMD ] ; then # do some magic; See below for an example. fi I could invent some wrapper script that looks for gij first then j2sdk, and have an option -jvm=gij to override it, but I'm thinking there's got to be a better, more standard way. This has probably been No. That why there was a big policy discussion last year and findjava was invented. See http://java.debian.net/index.php/CommonJavaPackaging for more information about findjava and other tools (and about how other packaging groups are working around this problem). discussed before, but I was too bust to follow the long threads at the time. Could you possibly say what the results of those discussions were, or suggest how to handle this issue? The 'suggested' way was: wait for sarge, do another discussion, do the implementation and then decide on the proposal. Seems that Stefan took some of the ideas and weent for his own proposal (Stefan, may I ask, why you didn't say something at that time?). Anyway, there is currently no way to do something else than for java in list of known working locations of JVMS ; do if [ -x $java ] ; then break; fi done exec $java ... And if you want to make dpkg happy, you even have to do something like gij | kaffe | j2sdk1.4 |... |java2-runtime (the last will propably work, as it has no install candiate in main. Only sun derived JVM will provide such a thing. java1-runtime is provided with sablevm, which will not run bugwatcher) at java.util.zip.Inflater.end(Native Method) at java.util.zip.Inflater.end(Inflater.java:294) AFAIK, I've seen that with BD debian package (see the eclipse buglog). Debian BD package are propably compiled agains a libSomething version, which has changed in debian. That's at least my explanation, newer (e.g.: not packaged, but -bin download) seems to work fine. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: From contrib to main
Hallo Stefan, * Stefan Gybas wrote: So I've set up a PhpWiki at http://java.debian.net/. Any objections to moving this page to PhpWiki? Would you mind, if this page was used for some other brainstorming, too? Dalibor is currently looking for some space to put the 'one packageing system for all' project going and before we take ages to get a freedesktop.org place, java.debian.net might be a alternative. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Common packaging: Wiki Site created
Hallo! As a result of Dalibor Topic's effort to get some common goals and needs from all the different java packagers, I got a Wiki to get the brainstorming startet. Please add your thoughts to the pages, describing, what you have and what you want/need/expect from a common set of tools/policies. The main page is on http://java.debian.net/index.php/CommonJavaPackaging The idea is, to start on that page and move the whole thing to 'a proper .org' later, when we have something to show around. Enjoy! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: From contrib to main
Hallo Arnaud, * Arnaud Vandyck wrote: I'm not a wiki guru, so please, every maintainer (or not) can update the page, thanks. Also, please, note that with the 1.1.3 release of kaffe, a lot of packages can now be build with it. done... Last but not least, 'cdbs' could be *THE* way to build the Debian-java packages! When I get time to do the eclipse3.0 builds, I will... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
Hallo Jerry, * Jerry Haltom wrote: What is the chance of having mpkg-j2sdk in main? Almost none: If we upload it (or it successor), it will go to contrib due to unfreeness of JDKs. If Sun derived JDKs switch to a Licence, we can use in main, it will be packaged and uploaded to main and mpkg-j2sdk will not be needed anymore. So the answer is: We can have it in contrib. Actually now. Takashi, didn't you want to do the upload? Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
Hallo Daniel, * Daniel Bonniot wrote: You mean that optional.jar has specific knowledge about jython? I'm not sure about jython (haven't looked), but optional.jar has the glue for junit (-junit task). Junit knows nothing about ant. This means that if any package wants to use a task in its build, it will Build-Depends: on ant and will think that it works. That should be OK if it needs a core or optional ant task. AFAIK the junit task is in the optional.jar. In the current setup, it will. With your setup, all packages, which will use a additional task need to Build-Depends: on junit, jython or whatever. If a package needs the jython task, it seems normal to me that it would need to Build-depend on both ant and jython. If thats consensus (sp?), so it be :) On http://ant.apache.org/manual/optionaltasklist.html I don't see any mention of jython. There is a antlr task, though. Does jython now belong to the optional tasks of ant upstream? I'm not sure, but if ant Depends on jython, it seem so... What you suggests is 'could be used from make programms' Suggests: make. The difference is that no 'glue' is needed for a Makefile to make use of a program. Yes, thats true. Only that a user won't know the difference... This is already done: ant dows provide all tasks in optional.jar and IMO, it shouldn't Suggests: ant :) Are you implying that only ant is supposed to provide ant tasks? No, but all other packages will have mostly one purpose: adding a task. For them to Depends: on ant would be kind of natural. [splitting optional.jar] It's a possible design, which sounds ok to me. Alternatively, what would be wrong with including the task in the package that provides the underlying facility? Nothing, but it's quite a task to coordinate that or even provide pacthes for upstream and telling apache ants people to stop including that tak in there distribution... Please note, that the gentoo guys (gentoo-java ML) currently discuss the same problem: They have the problem that ant requires all underlying programm/library/whatever be available at buildtime. Which is brain-dead, do we agree on that? Besides violating our Policy, as I explained. We have the same problem (optional.jar surely will not compile without junit installed), but we distribute binary packages, so we could add only suggests and the actual packages, which use the task could Depends: on the 'functionality' package. gentoo doesn't have that option, as they build from source... Anyway, the more I have to do with java packaging, the more braindead it seems to me... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ant dependency on jython and antlr
Hallo Daniel, * Daniel Bonniot wrote: AFAIK the junit task is in the optional.jar. Agreed with that. The change concerned jython and antlr. Ok, after some more thought I've finaly understood, why there were 'dangling symlinks'. The jython.jar had to be symlinked into /usr/share/ant/libs too. This will not happen anymore, if we could agree on the proposed policy: You would just add a DEPENDS=... line, which would give you the jars via 'java-config --all ant' (omitting any package, which it can't find). No symlinks nessesary. Tasks could actually be added via a $HOME/.antrc file, giving the user the possibilty to choose from different implementations. Regarding the symlinks, I think they rather belong to jyton and antlr, as this makes sure they are not dangling. However I'm fine with the original solution too (have them in ant). Dangling symlinks are not a policy violation or As said above: if we agree on java-config to sort out the CLASSPATH, we don't need any symlinks anymore. Anyway, the more I have to do with java packaging, the more braindead it seems to me... Now, don't be pessimistic! There _has_ to be a way to do things right ;-) Of course. But mostly it is something which the upstream author hasn't even thought about. Just think about the whole 'not sun-derived' JVM mess... For example the javadoc task, which is IMO a very essetial task, will not work with pure 'main' packages). [EMAIL PROTECTED]:~/psgr$ /usr/lib/kaffe/bin/javadoc java.lang.ClassNotFoundException: sun.tools.javadoc.Main at kaffe.lang.AppClassLoader.findClass (AppClassLoader.java:296) at java.lang.ClassLoader.loadClass (ClassLoader.java:142) Or packaging all dependencies in one package, like most java apps do... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
Hallo Jerry, * Jerry Haltom wrote: make-j2sdk itself depends on having non-free stuff installed? I thought it was just a little script to create a .deb from a Sun provided SDK. It depends on a *-bin download, which is unfree (and not even packaged). In general, install for unfree things ar ein contrib. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [FW] Accepted kaffe 1:1.1.1-5.1 (i386 source)
Hallo Dalibor, * Dalibor Topic wrote: Can someone certify, that this kaffe version is able to run eclipse 2.1.x? It runs it quite O.K. on my box, and rather fast. But you need to add the libswt-gtk.so directory to LD_LIBRARY_PATH. That isn'T a problem, as I do that anyway in my startscript... The trouble is that you also need to do a bit of configuration, like setup Eclipse to use kaffe's rt.jar to build, etc, which may be a little hard for someone who's novice to both Java Eclipse. I had problems getting Eclipse to use Kaffe as a Standard VM, maybe Mark Wielaard can help there, I've CC:ed him. I will have a look at that (I think I remember a post on one of the ML) and add that to the README or patch it in. Give it a try and judge for yourself. It's not 100% stable, though, the log file shows that some things still break. But there is definitely a large improvement since 1.1.2. I haven't had a chance to do it and I think it won't happen before Xmas. Personal question: Would you do development with eclipse on kaffe? Without swearing every 5 minutes, because something breaks? Thats aproximatly my barrier to add kaffe to the Depends: line and to the findjava (internal function, not the proposed shell script) search path. BTW: is anyone still interested in this Proposal? Sometime ago I asked Stephan to include it in java-common (the tools), but I got no response. Should I package a seperate package and ask for a sponsor for it, so that I can start to send some patches? I'm interested, as it would be an improvement over the current situation in my opinion. But I'm not a DD ;) I'm neither... Btw, how did your conversation with JPackage guys end up? They seem to have some ideas in common with with debian-java, so I was wondering if a distribution independant Java application/library packaging effort would have a standing chance. JPackage currently has the policy, that they add every jar to the classpath and treat JDK1.3+JAXP=JDK1.4. They use virtual packages fo this and something like the once proposed 'sun-derived-1.4' interface. They don't have a possibility to use non sun-derived JDKs, until they will be as mature as a sun-derived (mature as in 'add as many jars until it is complete and it will work'). They also rely on a JAVA_HOME like interface. The main work (as in 'findjava' and 'java-config --getclasspath') will be done at postinst level, where symlinks are used to setup the environment. The thing is quite complicated and 'developer-friendly' (the model case was ant and being able to adjust the classpath, so that ant can be used with different implementations of some tasks) and low level. I asked them how they will manage kaffe and gij and the answer was: They should get 'mature enough' and it will work out. There is a policy in CVS, but quite hidden due to the ViewCVS version, which will show up branches in the attic. Funnily, I had also a look at gentoo, and they came up with some scripts 'inbetween' the debian java proposal and Jpackage ones. The whole issue would benefit from some standards, prefereable developed and promoted from freedesktop.org (JPackage was interested in such a project). Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: J2SDK question
Hallo Marco, * Marco Bresciani wrote: Can I use J2SDK on Debian? To install it 'the debian way', use j2se-package or mpkg-j2sdk: deb http://www.stud.uni-karlsruhe.de/~ude2 debian/ deb-src http://www.stud.uni-karlsruhe.de/~ude2 debian/ I can't recomend the Blackdown *debian* packages, at least eclipse will not work with it on a current unstable distribution. I'm not sure, how the latest *-bin download will workout. Usuall BD was better than the sun-linux version. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Java packaging (was: [FW] Accepted kaffe 1:1.1.1-5.1 (i386 source))
in, when you do such a proposal :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java packaging
Hallo Daniel,
* Daniel Bonniot wrote:
That's great. Will you keep both 2.1 and 3.0 in parallel in Debian, or
simply upgrade the packages to 3.0?
My current planing looks like this:
* split the package into at several source packages, so that swt-gtk
and the eclipse compiler can go to main and the rest is split into
smaller packages (RCP/Platform, JDT/PDE).
* do the packaging with CVS (I'm fed up with downloading 60+ MB) and
with a 'to be deeloped' script, which generates the build.xml for
some features (basicly done by the eclipse.pde.build plugin).
SWT is actually ready to keep both version installed, but I think that
I don't want to have the problems of two eclispe versions installed.
If it's as easy as changing /usr/{local/,}{lib,share}/eclipse into
eclipse3.0, then I could probably maintain both versions. But I
suspect that there arn't that many reasons to keep the old 2.1 builds
around, when you can have the latest and greatest. Especially with
eclipse, where you have very rapid development and newer version
really have some great new features.
I will probably shrink the eclipse2.1 builds to a 'swt2.1' build, so
that I can keep the library (which is needed by one ITP), if the 3.0
SWT implementation isn't backward compatible (which I don't suspect,
SWT is very strict in that respect)
Anyway, I will be away over Xmas and I hope that I can do some work
straigt after new year. The next available date will then be end of
february (after my exams...).
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse keeps crashing
Hallo Arnaud, * Arnaud Vandyck wrote: Jan Schulz [EMAIL PROTECTED] writes: [if anybody knows how to get grep accepting .*(eclipse|swt).*...] use egrep instead of grep (and don't forget the ). And again something learned... Thanks! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse problems
Hallo Mariano, * Mariano García wrote: java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Control why does eclipse crash now??? It doesn't find the SWT implementation. Please compare what your * $HOME/.eclipse/eclipsrc - WS=... * update-alternatives --display libswt2.1-java says and whether both (one, if only one of the SWT packages are installed) links are actually there (if not, then it would be a bug). The problem with this feature is, that it seems that this problem is a little too common and I should write some test code to check, whether a requested version is actually installed by he package manager. This feature (changing the SWT implemantation on the fly) is debian (and now JPackage.org - Java RPM packages) specific and NOT supported by upstream. Seems that I was too optimistic about the 'fail quote'. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse crash
Hallo Bear, * Bear Giles wrote: I can't help you because eclipse is crashing every time I run it - I get a NoClassDefFoundError: org/eclipse/swt/widgets/Control thrown. I'm not sure what to make of this since I have libswt2.1-motif-java installed. $HOME/.eclipse/eclipsrc - s/gtk/motif/ ? Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse-Backport for Woody
Hallo Christian, * Christian Stalp wrote: does anybody know where I can get a Eclipse-Backport for Woody? Or does anybody here made this by himself? Until I switched to unstable, I developed the packages on stable+backports. Here you go: - /etc/apt/sources.list deb-src htttp://www.katzien.de/debian/eclipse ./ deb GNOME 2.2 Backports - www.apt-get.org sudo apt-get build-dep eclipse-sdk apt-get source -b eclipse-sdk sudo dpkg -i *deb You may need do do some download from unstable and install them by hand (patch and other small packages). Be aware, that there is currently a bug in the help system, which I have to solve relly soon... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse: motif vs. lesstif?
Hallo Bear,
* Bear Giles wrote:
I don't think this rises to the level of a 'bug,' but maybe
somebody here knows the answer. Why does eclipse depend on motif
instead of motif | lesstif?
The eclipse.org swt FAQ states, that lestiff does not implement
everything what swt needs:
--8-:- snip -:-8-:- snip -:-8--
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/faq.html
Q: Why do I get the warning XmParseMappingCreate() is not implemented
yet on linux/motif?
A: This warning is shown if you're accessing installed LessTif
libraries instead of the shipped OpenMotif libraries. Although Eclipse
will start fine with LessTif libraries, its subsequent operation is
not optimal. If you see this warning, add the eclipse install
directory to your LD_LIBRARY_PATH before launching eclipse. For
example, if you are using csh:
setenv LD_LIBRARY_PATH /opt/eclipse:${LD_LIBRARY_PATH}
--8-:- snip -:-8-:- snip -:-8--
Another thing is, that you get this here:
[EMAIL PROTECTED]:~/debian/src/kickpim$ dpkg -L libmotif3 |grep Xm
/usr/X11R6/lib/libXm.so.3.0.1
/usr/X11R6/lib/libXm.so.3
[EMAIL PROTECTED]:~/debian/src/kickpim$ dpkg -L lesstif2 |grep Xm
/usr/lib/libXm.so.2.0.1
/usr/lib/libXm.so.2
So I think you have to compile it agains one or the other and can't
interchange them before runtime.
I must admit, that I haven't tried to compile swt-motif against
lesstif, having read the above notice. As I come from java, I also
have not so much knowledge with native compiling and the openmotif
thing worked out of the box.
If anyone can give me a idea how to change that, I will try and test.
Having it build with lesstif would give me one headache less when I
package the 3.0 Stream, which will feature swt-gtk in main and
therefor in a different source package...
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo Takashi, * Takashi Okamoto wrote: Maybe most of people like mpkg-xx name. I suggest 'mpkg-j2se'. It's more intuitive. No idea, if people like it, but I do :) I would even go further to a mpkg-java script. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo Hubert, * Hubert Schmid wrote: I don't insist on this name. Are there any further packages in Debian (except kernel-package) that build Debian packages? If someone has a good name for the package and/or the executable shell script, then I will rename the package. I don't know of any more, but I have a mpkg-opera waiting to be more usefull :) I find the 'mpkg-' quite nice wrt indicating a installer script which results in a package. Between, I added support for Blackdown J2RE/SDK 1.3 and 1.4 and fixed a problem with woody (du --apparent-size). I would like to send a patch for IBM1.4 but I haven't heard from you since my last mail. I really would like to get the new policy added to your script, but I fear that there are some problems with the auxilary packages: The java-config file would go into the aux package and so any package, which want to use a JVM via findjava needs to depend on either the chain 'package-packagedebian' or directly on 'packagedebian'. The second is IMO ugly (everytime the suffix...) and the first would require, that package depends on packagedebian, which would mean that the package is basicly uninstalable: packagedebian will be installed via apt, and the package itself only via 'sudo dpkg -i'. In both situation it would mean, that the dependecies of each package are not satisfied. Both Depends: on each other, but the current package manager which wants to install the package does not know about the other. IMO it would be nice, if that could be solved first, otherwiese we need lots of 'Conflicts:' lines just for backward compatibility. My idea was it to rename the 'upstream package' to package-upstream and 'packagedebian' to package. That way, it looks clean if a app depends on sun-jdk-1.4 and the dependency chain is ok: first install the upstream package via dpkg and then the debian glue via apt. My 0.02¤ Jan -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package for the proposed new java policy
Hallo,
* /me wrote:
deb[-src] http://www.katzien.de/debian/java ./
I've just uploade a new version of 'new-java-policy' to that location,
which only includes the relevant tools in /usr/bin and all else in
/usr/share/doc/new-java-policy/{,examples}
The changelog:
new-java-policy (0.6) unstable; urgency=low
* moved examples into /usr/share/doc/new-java-policy/examples
- to use the examples, do a
'export JAVA_CONFIG_DIR=/usr/share/doc/new-java-policy/examples'
* changed dh_java manpage heading, which was still dh_python...
-- Jan Schulz [EMAIL PROTECTED] Sat, 8 Nov 2003 23:17:00 +0100
Included are:
* findjava -- a script to figure out the command to start a JVM
* java-config -- builds recursivly a CLASSPATH, based on package names
* java-config-update -- renews the contributed classpath entries
- used on install time
* dh_java -- debhelper script to manage java-config files with java packages
* manpages for all the above and java-config-file(5) and findjavarc(5)
* example java-config files for all jav apackages I had installed:
$ export JAVA_CONFIG_DIR=/usr/share/doc/new-java-policy/examples
- use the scripts
* the proposed policy as /usr/share/doc/new-java-policy/policy.txt
Example session:
[EMAIL PROTECTED]:~$ export JAVA_CONFIG_DIR=/usr/share/doc/new-java-policy/examples/
[EMAIL PROTECTED]:~$ findjava --client sun-java-vm-1.4
/usr/lib/j2sdk1.4/bin/java -Djava.library.path=/usr/lib/jni -client
[EMAIL PROTECTED]:~$ findjava --client kaffe sun-java-vm-1.4
/usr/bin/kaffe
[EMAIL PROTECTED]:~$ findjava --server kaffe sun-java-vm-1.4
/usr/lib/j2sdk1.4/bin/java -Djava.library.path=/usr/lib/jni -server
[EMAIL PROTECTED]:~$ java-config --all tomcat4
/usr/share/java/xercesImpl.jar:/usr/share/java/xmlParserAPIs.jar:/usr/share/java/servlet-2.3.jar:/usr/share/java/regexp.jar:/usr/share/java/commons-beanutils.jar:/usr/share/java/commons-collections.jar:/usr/share/java/commons-logging-api.jar:/usr/share/java/commons-logging.jar:/usr/share/java/logkit.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/ant-optional.jar:/usr/share/java/ant-1.5.jar
[EMAIL PROTECTED]:~$ java-config --classpath ant
/usr/share/java/ant-optional.jar:/usr/share/java/ant-1.5.jar
[EMAIL PROTECTED]:~$ java-config --all ant
/usr/share/java/ant-optional.jar:/usr/share/java/ant-1.5.jar:/usr/share/java/antlr.jar:/usr/share/java/antlrall.jar:/usr/share/java/junit.jar:/usr/share/java/jython.jar:/usr/share/java/libreadline-java.jar:/usr/share/java/commons-logging-api.jar:/usr/share/java/commons-logging.jar:/usr/share/java/logkit.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/bcel-5.1.jar:/usr/share/java/bcel.jar:/usr/share/java/regexp.jar:/usr/share/java/xml-apis.jar:/usr/share/java/xalan2.jar:/usr/share/java/jdepend.jar
[EMAIL PROTECTED]:~$ java-config --contrib ant
/usr/share/java/antlr.jar:/usr/share/java/antlrall.jar:/usr/share/java/junit.jar:/usr/share/java/jython.jar:/usr/share/java/libreadline-java.jar:/usr/share/java/commons-logging-api.jar:/usr/share/java/commons-logging.jar:/usr/share/java/logkit.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/bcel-5.1.jar:/usr/share/java/bcel.jar:/usr/share/java/regexp.jar:/usr/share/java/xml-apis.jar:/usr/share/java/xalan2.jar:/usr/share/java/jdepend.jar
# libswt2.1-*-java already have java-config files
[EMAIL PROTECTED]:~$ export JAVA_CONFIG_DIR=
# libswt2.1-java is a virtual package and the java-config file is u-a
# managed
[EMAIL PROTECTED]:~$ java-config --all libswt2.1-java
/usr/share/java/swt2.1-motif.jar
[EMAIL PROTECTED]:~$ java-config --all libswt2.1-motif-java
/usr/share/java/swt2.1-motif.jar
[EMAIL PROTECTED]:~$ java-config --all libswt2.1-gtk2-java
/usr/share/java/swt2.1-gtk.jar:/usr/share/java/swt-pi2.1-gtk.jar
Any feedback welcome!
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package for the proposed new java policy
Hallo Daniel, * Daniel Bonniot wrote: Jan, thanks for the upload. * moved examples into /usr/share/doc/new-java-policy/examples - to use the examples, do a 'export JAVA_CONFIG_DIR=/usr/share/doc/new-java-policy/examples' The manpage of findjava is not up to date with this. It does not mention the JAVA_CONFIG_DIR, but speaks about /etc/findjavarc, which is not installed by the package. Is this normal? Yes: the above was actually introduced to make unit testing posible. The only thing it does is set the search patrh for java-config files (which is usually /usr/share/java-config) to a different location (in this case teh examples location) The findjavarc is used to set one JVM as the default one. See findjavarc(5). there is no findjavrc installed, as the I haven't had time to think about a easy way to give the user a nice default/exapmple conffile. Maybe I should add such a file in /etc, so that users can seen what they can do... If I understand, the advantage of having a config dir is that each VM could install its own file there, right? So it should probably be something like /etc/findjava.d/ No, you install a java-config file for each JVM, java package and ant-environment. The format for each is described in java-config-file(5) The java config dir is simple there for debugging purpose. It will probably be removed when I release a final version. Normally, you will put the java-config file into /usr/share/java-config I also expected `findjava -h` to print some usage message, but it seems -h is unknown, and unknown options are silently ignored. This isn't yet implemented. Basicly that was, because I wasn't sure, how that could interfere with other things (think `findjava --all tomcat4 -h` - bad if instead of tomcats classpath now the help is outputted). I will add some help, which is then ouputted to stderr and exited with an error code. All information is in the manpage. It took more time to write the manpages than to write the scritps... I hope they are as usefull :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo Hubert, * Hubert Schmid wrote: On Mon, 27 Oct 2003, Jan Schulz wrote: * Hubert Schmid wrote: nitpick: I find the mpkg-* idea better :) What about mpkg-java or mpkg-j2se? At least it make sit clear that a package is created. I will think about this. But at least, the package and the script should have the same name. True. On the other hand, this would be a nice place to collect all 'contrib' java scripts. But thats probably something for later... happen with it :) You can get the proposed policy from deb http://www.katzien.de/debian/java ./ I will read the proposed policy this weekend. I could send you a aptch, which woul 'enable' the proposed policy with your scripts. Basicly, it boils down to including a file in /usr/share/java-config, which describes the included java and ant environment. I will package the blackdown versions next. But I could need some help with the IBM packages, because I don't like to download these files. Ok, I take the 1.4 IBM and sent the patch to you. I hope I have time this weekend to do that, otherwise it could take some more days... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Undistributable java in main
Hallo Dalibor, * Dalibor Topic wrote: * figure out how you want to interpret the GPL in this case. The rest follows from that. Problems not touched: *execution* of GPL-incompatible code using GPLed libs and/or GPLed JVMs is beyond the scope of this message. Could you please take this two thing to debian-legal and get a opinion there. Anyway: if thats true, that it will kill kaffe in debian, as we could not use it with almost any programm, because in one way or another, they all include apache licensed libs (- jakarta project). I hate licenses... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Java and gpl (was: Undistributable java in main)
Hallo Dalibor, * Dalibor Topic wrote: Anyway: if thats true, that it will kill kaffe in debian, as we could not use it with almost any programm, because in one way or another, they all include apache licensed libs (- jakarta project). Don't agree. ;) Even if this was true, it would be good enough for *compiling* all the GPLd java apps. I guess there must be some, judging by freshmeat: 1051 GPLd Java apps. By far the most popular license for Java apps. Should we have a look, which of them have a exception to run it with non GPL'ed libs? And how many require features which are not available GPL'ed (^=sun derived)? - basicly the package is then not legally compile/runable... Just some month ago I got a mail from a guy who ITP a java app based on SWT (- CPL'ed). Upstream was GPL'ed and had *no* exeption... As Grzegorz said, he isn't even touching *execution*, that's another field where we are bound to disagree ;) And that's why I said 'take the two points to debian-legal'. If both are 'no-no', almost all apps will either Conflicts: with kaffe (todays policy, as I'm not sure whether kaffe is /usr/bin/java) or not ask for kaffe in the findjava call (hopefully the new policy, if hintsome more DDs would finaly say 'make it so'/hint) Anyway, we're switching kaffe's class library over to GNU Classpath, which is GPL + linking exception, and that should make the people who support FSFs interpretation happy, too, as GNU Classpath explicitely allows linking to it. Good. That will be one mess less... :) I hate licenses... Don't agree. GPL is quite nice for me, the trouble is that the rest of the world sometimes uses something incompatible and then we have to play lawyers to decide what's allowed and what not ;) Actually I'm more a fan of 'do what you want' (including: use it with nonfree stuff), which GPL lets me not. QTs GPL license is the reason, why I have a eclipse as gnome app and not with my nice stylish KDE :) I think eclipse.org has a demo version ready (or had), but the lawers stoped them, because it would have meant to GPL eclipse which would mean, that eclipse couldn't be used comercially (- closed source). Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
eclipse packages for !i386 platforms for sarge release
Hallo! A quick look at my 'update-excuses' [1] showed, that eclipse is currently hold back because of several issues: * Some libs, which can't do anything about... * As there are no autobuilder in contrib, I need to provide the platform dependend packages for !i386 platforms. I have no idea, how I should get that happen? Is there anybody, which has the time to build eclipse on PPC or other platforms and can upload the packages? * Another issue is the 'not available' j2sdk1.3/1.4. How is that dealt with? As eclipse will not run without such a thing, I don't know how this can be worked around other than removing all platforms, which have no working JDK [2],[3]: BD/SUN(?): 1.3: powerpc, i386, sparc 1.4: i386, sparc IBM: 1.3: i386, s390(?) 1.4: i386, s390(?) I'm actually not sure, what IBM offers there: They have a JDK for 32-bit xSeries (Intel compatible), 32-bit iSeries/pSeries, 64-bit iSeries/pSeries, 31-bit zSeries (S/390) and 64-bit zSeries (S/390). Maybe someone can enlighten me, what the 'iSeries/pSeries' is and of the last two bits are what debian calls s390... Currently eclipse is shiped mostly as 'Architecture: all', but there are platform dependend modules (JNI - SWT, other). Also, this libs are not 64bit clean, which is why the libs are already not shiped as 'Arch: any'. What is the recomended way to deal with that problem? Ship as 'Architecture: powerpc i386 s390 sparc' instead of 'Arch: all' and be done with it? Also, will eclipse, with missing dependencies (- jdks are not packged), move into testing? Theoretically (actually: practically) SWT is runable with kaffe, so swt could be build on other platforms. Eclipse on the other hand will not run on a current kaffe. I'm also very interested in if that's all I can do to get eclipse into the sarge release (other than getting done with the outstanding RC bug...) Jan [1] http://packages.qa.debian.org/e/eclipse.html [2] http://www.blackdown.org/java-linux/java2-status/jdk1.4-status.html [3] https://www6.software.ibm.com/dl/lxdk/lxdk-p signature.asc Description: Digital signature
Re: eclipse packages for !i386 platforms for sarge release
Hallo Per, * Per Bothner wrote: However, eclipse will run on gcj: Yes, I'm aware of that. Unfortunatelly, they use a patched gij/gcj, which is not available in debian yet (AFAIK, they have a branch, which is not completly integrated into HEAD yet. At least that was the message some weeks ago). They also patched eclipse a bit and AFAIK, they haven't made the patches available. Also, I have to either compile it to native, which I probably will not do, at least not without creating a new package for the 'normal' JIT based eclipse. Or I will have to run it woth gij, which is AFAIK interpreter only mode (I've no idea, how it competes with JIT, though). Right now, the gij just crashes after about a minute of 90% CPU... To sum it up: *Right now* I have more hope on kaffe doing the job than gij. Also, the next eclipse version 3.0 (which is next on my TODO) will require 1.4 complient JDKs, and I'm not sure, how far the free JDK are (I guess most can be done with including certain API) in that respect. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo J., * J. R. Westmoreland wrote: It would also be nice if the script could handle j2ee as well as j2sdk or j2re. It shoulkd be quite easy to implement that: It needs a script which 'knows' the downlaod files and installs it into a tmp location. It also needs a package, which sets up the 'debian files' for the package. Considre it a nice pertunity to do some cutpaste coding :) I will propably do the IBMJDK1.4... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo J., * J. R. Westmoreland wrote: I thought that I understood that the package itself was not FREE not that the software to make the package was not FREE? E.g., the j2sdk is NOT FREE but the software that creates the package IS FREE. Therefore, one could include the script in java-common and ALL parts of the java-common are FREE. Installer depend on unfree software and therefor at least must go into contrib. There was some discussion, whether they should altogether go to non-free. See debian-devel for that. Therfor IMO: no 'installer' can go into java-common and mpkg-java/j2se-package must also go into contrib... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)
Hallo Hubert, * Hubert Schmid wrote: j2se-package creates a (binary) Debian package from an upstream binary Java(TM) 2 SDK or RE distribution, in order to easily install the non-free Java VMs on Debian machines. nitpick: I find the mpkg-* idea better :) What about mpkg-java or mpkg-j2se? At least it make sit clear that a package is created. The new version works as follows: - For each upstream release from each vendor, there is a peer-package, that does the required stuff to integrate the package into debian. Currently it only updates alternatives, but it may also contain wrapper scripts, menu entries, etc. This sounds great. I was about to write some patches, which would allow 'plugin able' vendor and version specifc parts of the mpkg-j2sdk script, but this seems great from first look. BTW: would you mind to support the proposed java policy? Some parts were written with mpkg.java in mind, so it would be great if the proposed things could happen with it :) You can get the proposed policy from deb http://www.katzien.de/debian/java ./ - new-java-policy I'm downloading your new packages right now and will try to get some patches to you for this. I hope you will accept them. If you would tell me which version you will do next, Icould help you with that. I have a IBM 1.4 JDK here, which I would like to debianize... The advantage of this separation is, that the most problems can be easily fixed in the peer-package and the user doesn't need rebuild the binary package each time. True. It would be nice, if the whole packages could be merged into one source package. Please don't hesitate to ask for help. I have some interest in seeing this package making it into debian, completly with support for the proposed policy. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#212863: new java policy: ok or not?
Hallo Arnaud, * Arnaud Vandyck wrote: So (even if I'm not yet a DD), I second your proposal if point 3 is respected. s/(.*),// - Seems that I got my one and only DD approval 'the other way' :( On the other hand: Congratulation! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: eclipse hyades ?
Hallo Kristian,
* Kristian G. Kvilekval wrote:
Is this already available or
does somebody have package for this?
This is not available yet (AFAIK: :). I do plan to write a
'eclipseplugin2deb' script, which will allow for faster package
creation of eclipse plugins, but that will take some time and I won't
start that until after the 3.0 switch (which I will do after the RCP
changes, depending on stability). Also, the next plugin I will convert
is probably CDT (also after teh 3.0 switch).
If you need some additional help on debian-eclipse packaging, don't
hesitate to conatact me.
If you only want to install hyades, simple drop it into
/usr/local/share/eclipse/{plugins,features) or into
$HOME/.eclipse/eclipse/{plugins,features), depending whether you have
admin rights or not :)
Both sites will be picked up by the debian eclipse.
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: new java policy: ok or not?
Hallo Arnaud, * Arnaud Vandyck wrote: Jan Schulz [EMAIL PROTECTED] wrote: * Arnaud Vandyck wrote: So I did not follow all the thread. I appreciate the summary effort and after reading this mail I have no special argument to stop your proposal but I do not want to second it if it's a MUST in the policy. You know, I understand that the proposal, as it is, is *not* secondable, as it misses some testing first. Debian policy is based on 'common practise' (which the old java policy, in most parts, was surely not), so I hope I can implement wide parts of it before asking for a policy change. But without any 'make it so' comments, or some of the bigger java maintainers, which change their packages, I will not get this changes made and so the policy will not get tested and in the end nothing changes. something that makes a bug 'serious'. First I'm not yet a DD so even if I can make the changes soon, I'll need to ask a sponsor, I'm not sure when my packages will be uploaded. Second, I'm sure some DD just don't have the time to change all their packages. I don't ask for a upload only for the sake of adding the changes for the porposal. What I ask for is 'if I have to upload the apckage the next time, this file will also be part of it'. I don't expect to file 100 wishlist bugs during the next days, but I will spread most of the changes over the next weeks. OK, it's a line change for a library, but you also have to build the .jars file to complete Yep: during the next requied upload. (also, I did not catch if there was different jar groups depending on the virtual machine?.. No. The java runtime requirement is 'located' in teh java apps (which have to call 'findjava' in the starter script). Anyway, this is a really good point, which I overlooked during teh discussion. This will basicly mean that we can remove the |A package must depend on the disjunction of all JVMs with |which it has been tested succesfully. Part from the library section. Or replace it with |A library only package should not depend on any java virtual machine |package. For VM maintainer it will be a cp and maybe some looking into the doc and adding the right flags, where I missed something. It seems to be really easy ;) Ean, any comment? :-D Yes, that's also still something I waiting for :) Although I think I will do much of the work, as I want to write the patch for mpkg-j2sdk... Well, if I understand, we can slowly begin the work of implementing your idea _without a policy change_ and when every packages does use the findjava wrapper a good policy text will be ready for inclusion into the java policy. Thanks, thats the first time someone said this. I hope some other will also write something along this lines. But for all this I need something more than 'wait for the sarge release and *restart* discussing *then*'. Sorry for the restart the discussion! ;) I don't much mind the restarting but much more the 'wait until after the discussion/...' part. Yes it seems resonable but I don't know if it will work on the long term... and I think the dependency of libraries in java is a java problem that must be solved in a java way: META-INF/MANIFEST.MF or something like this also in libraries, not only in applications. Or maybe an xml file or a property file in META-INF like the META-INF/services but I don't know this purpose very well. I'll discuss that with a co-worker and will try to study that in the futur weeks. If you do this, then you should start this discussion on a sun ML, so it is included there. But this will probably not work, as SUN will simple refuce to accept that there are 'non licensed' JVM. And thats the primary goal for such mechanism, for the rest it is too less 'finetuned' to make any difference. Anyway, I think this proposal is a big difference to the 'maybe it will start, maybe not' situation, which is currently happening, when you don't use some special tricks (JAVA_HOME), which are undocumented and not debian conform. I don't know if it's the better solution but if I'll be there to try your javafind package. I'll look for the informations you provide in the archives but once again, I'm not yet a DD and I'm very busy teaching java at the moment ;) but with 15 package to change you are quite a big 'do it' opinion :) 1° I don't think it's the better solution...; Better to the 'best' sollution or to the current solution? Thanks for teh reply! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: new java policy: ok or not?
Hallo Ben, * Ben Burton wrote: My only comment is that since sarge is purportedly so close to freeze and since this is more or less a complete policy rewrite, I think we should keep current java policy until after sarge. Yes, thats sensible :) Anyway, as I stated, I can't see a problem in implementing the new behaviour. Apart from a few packages, it will be something like if [ -x /usr/bin/findjava ] ; then POSSIBLE=kaffe sun-java-1.4 ... ; JAVACMD=$(findjava -client $POSSIBLE); fi if [ $JAVACMD = ] ; then # current magic to find a java fi if [ -x /usr/bin/java-config ] ; then PACKAGES= CLASSPATH=$(java-config --all $PACKAGES); else # current classpath magic fi I'm perfectly happy to have the scripts/etc in java-common/etc now, as long as they don't interfere with current behaviour and current policy. So that's one :) Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: new java policy: ok or not?
Hallo Arnaud, * Arnaud Vandyck wrote: Same for me, wait until sarge is out and let's restart the discussions about a new policy. Sorry, but that was exactly the reply I was *not* hoping for. IMO there is enough discussion and the whole thing needs some testing. I'm also willing to write most of the initial patches. What I'm not willing is just sit quiet until the *next* (and next...) discussion. To integrate this changes would be in most cases (we don't have that many java *apps*, but lots of libs) a 'cp debian/package.jars debian/package/usr/share/java-config/package' in debian/rules (or add dh_java during binary-indep). For VM maintainer it will be a cp and maybe some looking into the doc and adding the right flags, where I missed something. In the apps it would be CLASSPATH=$(java-config -all $PACKAGE), where $PACKAGE is all converted packages (I will start with the low-level libs and work my way up...) and adding the if .. else .. fi block around the current 'find java'-magic. All this *does* *not* interfere with current policy. But for all this I need something more than 'wait for the sarge release and *restart* discussing *then*'. I've no idea how far the sarge release is (the last bit I read said two weeks behind), but it will take at least another two month (more like after new year). There are several attemps to add something to the policy in the BTS and all have died. I'm not willing to let that happen to this attempt. So what I'm asking now for is either * Yes, I find this propsal reasonable and think it will work. I intent to add the patches to my packages, if they don't interfere with current policy. OR * No, this proposal sounds like it will not work and I don't want to make any changes to my packages. OR * IMO this points (give list!) are not well thought out and need to be looked into again. I intent to give up proposing this changes, if the second opinion is consensus or if noone replys to this. I'm sorry to say it this hard, but IMO it does no good to say 'later' all the time. Until now, there was almost no reaction form DDs and if, the questionable points were hopefully answered or the appropriated changes were made. What I want is some more comitment to this, so that I see that the work on this isn't wasted. And I'm also more than a bit fed up with this 'no reaction' attempt, especially when there is almost no work doing the change or just reading through the propsal and add a opinion. So, please make up your mind. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#212863: new java policy: ok or not?
Hallo Stefan, only to the list... * Stefan Gybas wrote: I also suggest to handle it this way. However, I think we can still make small changes to the Java Policy before sarge's release, e.g. remove the possibility to put Java classes in /usr/bin/ (using binfmt_misc). This would not affect any package. I second this (doesn't matter, as I'm not a DD yet), but IMO, if no package implements it, why does it matter anyway? IMHO our main focus should be getting current versions of Kaffe, SabelVM, Jikes, Classpath, gjdoc and all the other packages in contrib into testing before we start making major changes to the Java Policy. So most packages need a upload anyway, why not add this little bits. The code would be redunant or 'unused', if the proposed policy isn't followed. The only part where some breakage can happen is the apps, for the rest of the packages it's just adding a file. I'll work on this as soon as the new versions of tomcat4 and tomcat-connectors are finished. BTW: tomcat4 misses a manpage (/usr/bin/tomcat4, Policy 12.1) and it needs JAVA_HOME (- 9.9) set if started from the commandline (the second bug would BTW removed with implementing the new policy :). Have you looked into this or should I file some bugreports with patches? Patches should be fairly easy, especially if I anyway have a look at the tomcat starter script... :) Jan, adding sweets to the whip and SCNR :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: new java policy: ok or not?
Hallo, There seems to be no more questions, but unfortunatelly nonone has said something like 'do it' or 'file bugs with patches' or 'go testing' or whatever until now. I'm a little scared to go on, and ask Stefan for the temporary inclusion of the findjava and other scripts in java-common or the VM and package maintainer to include java-config-files, without such comments.. Also, I would like to start working on a patch for mpkg-j2sdk to include all the changes and to make the new policy bits working with the new policy. Aparat from the naming convention for the jar files, I can't see any 'conflicts' when having both policy implemented (and that's no big deal...). That's why I would like to take the same steps like the recent resolvconf transition, and supply patches, which supports both versions of policy. At first I will get in changes for runtime matters and finish with the 'ant-environment' changes at build-time. So, what I would like to hear is not a 'seconded' as required for a policy change, but something like 'lets see some testing and if successful we can go on and change the policy' from some debian developers. Looking at the list of Java package maintainerns, I would like to get the ok from at least some of (hopefully all maintainer with more than two packages with 'Depends: .*java.*' and who represent ~70% of the java packages): Arnaud Vandyck Stefan Gybas Takashi Okamoto Ola Lundqvist Ben Burton Mark Johnson Adam Majer Stephen Zander Robert Bihlmeyer Stephen Zander Tollef Fog Heen Grzegorz Prokopski I'm especially interested in the OK from Arnaud, Stefan, Takashi and Ola, who are representing more than 50% of the above list. Nice greetings, Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hello Dalibor, Thursday, October 9, 2003, 6:34:56 PM, you wrote: I'm waiting for the screams... /me screams: not the same discussion again! ;) Thanks! :) [...big snip, complete ACK...] Unfortunately, the Xerces J developers don't want to lose that 'feature' so the miserable code will stay in, preventing the next release of Xerces-J from being buildable on any free VM. Than I'm particulary happy, that eclipse will lose the internal xerces in the next version :) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hello Ean, Thursday, October 9, 2003, 7:33:22 AM, you wrote: For instance, if the Tomcat maintainer decides that compiling certain baseline classes with GCJ before running the main system with GIJ is a good idea then I can't see that findjava will elegantly accomodate that. The idea itself may be sound but probably doesn't belong in a common package and actually probably belongs in something like tomcat-gcj-booster.deb or somesuch. True. And this package will depend *only' on gcj and will not touch any java related things like jar files or java bytecode interpreeter. This things will be handled --more or less-- under normal debian policy. All things considered, I think that my preference is to have each VM provide some Debian-specific tightened up version of $JAVA_HOME that we specify in java-policy and then have $JAVA_HOME be managed by alternatives. IMO: JAVA_HOME is good for three things: * ant, which depends on the java property java.home set and some apps in java.home/bin/* * other apps, which rely on internal things in java.home * uses '$JAVA_HOME/bin/java to start the app The first is done in the 'ant-environment', which specifies a 'kind of' java.home, but the only requirement is 'it runs ant'. The second can't properly be helped in any other way than 'Depends: only sun dereived JVMs' The third can be trivaly helped by patching the startup script, which would probably anyway be needed bvecause of 'free VMs', which are surely not considered (think: internal options) in this startscripts. Did I miss something? Anyway, even if we specify a 'JAVA_HOME' layout, it will not help us with the alternative system. The problem with alternactives are quite different from why a JAVA_HOME layout would be usefull or not. No matter we are using '/usr/bin/java' or '/usr/lib/java-home[/bin/java]', the same problems will show up. We would then need a 'findjavahome' script. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hello Ean, Thursday, October 9, 2003, 10:26:10 PM, you wrote: They often use JAVA_HOME to find the executable, the base class libraries, The base classes shouldn't matter apart from ant bootclasspath, which is already included in the ant-environment. the compiler and jar. Both are usebale from ant: jar is replaced by a internal implementation based on zip classes and the compiler can be specified via short names or classfiles. Of course, that presents another set of issues with regard to alternatives. If JAVA_HOME points at /usr/lib/kaffe then how can javac = jikes and so forth. Have a look at the 'ant-environment' in teh proposed policy. I'm not saying that JAVA_HOME kicks ass or is even sane, it is just a widely used convention. Yes, and all usecases, which are interesting for debian are IMO done in slighly different, but much more saner ways with the new policy. From that perspective, shouldn't findjava just be /usr/bin/java? No. /usr/bin/java is expected to be a JVM, not something,w hich outputs a VM command. USer will use it for things like 'my first java app' and so on. Maybe it would be better to maintain the findjava-vm-binding as a separate package, so that bugs in one don't force exclusion of the other from testing? Sensible enough. If you would have a look at findjava and how it works, then it would be clear, that this *is* *already* *done* via the java-config-files. It is not as flexible as a 'execjava _*lots*_ of options mainClass' with different implemntations, but I can't think of a situation, where so much flexibility is needed. If you look at the java apps in debian, none of them does any JVM specific tuning. findjava is flexible as well, up to a point and I think that this point is *far* above any need of a package. All of you: please read the proposed policy and the scripts, which are mentiond there and also the helper scripts. There is no need to hit each otheres over the head with additional requirements, if much of the work is are already done. :) They are easily getabale by deb http://www.katzien.de/debian/java ./ - apt-get install new-java-policy Proposed policy: zless /usr/share/doc/new-java-policy/policy.txt.gz Manpages: java-config(1), java-config-file(5), findjava(1), findjavarc(5), dh_java(1), update-java-config(1) And try the scripts: findjava [--server|--client|] kaffe sun-java-1.4 sablevm gij java-config [--all | --contrib |--classpath] $PACKAGE (where $PACKAGE is one of `ls /usr/share/java-config/` dh_java with a debian-dir with package.java and package.jars (see manpage) For the ant-environment, see the java-config-files of kaffe and sun-java-1.4 in /usr/share/java-config. I hope once this is common, I can persuade Stephan to include such things in the Common Debian Build System, so that they can be used like with the 'findjava' script. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: java-common: New java policy including tools to manage the changes
Hello Ean, Wednesday, October 8, 2003, 6:22:49 AM, you wrote: I still don't understand what this achieves that alternatives do not. Imagine this situation: Application needs a special feature, which is implemented in about half the java alternatives. /usr/bin/java will be set by all java binaries and in this case, /usr/bin/java is set by a package, which does not implement the requirements. There is a second installed java package, which does implement it. - apt will see all dependencies fullfiled, app will call /usr/bin/java and will not run. The workaround would be to follow the symlinks, but that would be the working *around* teh alternative system *and* you would end up with the 'findjava' code in every starter script (as the fallback, when /usr/bin/java isn't working). You get a similar 'feature' with the /etc/findjavarc and 'PREFERRED_...' variable. There is nothing particularly special about Java that requires a more elaborate alternatives mechanism than any other interpreter. IMO there is. See the discussion in debian-java, where this was turned over and over again. If the wrapper script for each VM does its job properly then the classpath should get set to what it needs to be and the VM will be invoked with all the proper conventions. This isn't the problem at all. The problem is that some java VMs will be able to start something and others will not. It would seem to me that findjava will simply invoke whichever VM it Please read the manpage of findjava and how it is used. It does not invoke anything, it just outputs the 'java command' to stdout. It garantees, that this outputed command is available on this system. If you need more than this, you can still do some magic based on this. finds first in its list of VMs and that will be that. It loses the priority mechanism of the alternatives scheme and doesn't really add The priorites were also discusssed and the 'would be' consensus was, that we can't assign different priorities without having a big row. based on what facts will you assign priorities? And you could still end up in a situation, where a lower priority JVM will run a app, but a hiher priority JVM will not. that much that cannot be done with proper wrapper scripts for each VM. IMO for the basic function (starting a app with a classpath and a main class) it's already now enough. For more, you cannot specifiy it *enough* to satisfy every situation (like: enable the jitter with what option? Enable what GC with what option? What subset would you implement?) and IMO SUN should do this and not we. I may need to go back and read the earlier discussions more carefully but I never saw how the findjava script adds anything that cannot be achieved using the usual (and up til now sufficient) IMO the today mechanism is *not* sufficient. Have a look at the starterscripts of all big java papps how they find the java binary: all uses JAVA_HOME for it and /usr/bin/java as a fallback. Please read the script and what it does. Also there is a lot of mails about the 'alternatives are enough to find a java binary' discussion during the second edition of the proposal. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hello Daniel, Wednesday, October 8, 2003, 12:11:24 PM, you wrote: There seems to be some misunderstanding going on. Having not taken sides, I thought I would try to help clarify the positions. Thanks for summarizing it up! That's Ean's point. Each JVM has its own command line arguments, so code is needed to translate a standardized set of command line arguments to the JVM own format. We should not put this translation code in a common package, because then each maintainer will need to update it from time to time, and it will be a mess. IMO, and after having alook at sablevm, kaffe and gij during teh discussion: all of them are compatible enough to be used in the normal sense: export CLASSPATH - will result in a classpath, setup from basic classes and the added ones. JAVACMD Mainclass options IMO the only switch, which needs additional specification would be '-classpath' to include the runtime environment by default. I remember kaffe not setting it, but I think Ean made sure it is included during the 1.1 update. This is already done by the wrapper scripts. So findjava should not return the 'raw' binary, but the wrapper scripts (ie /usr/bin/gij-wrapper, not /usr/bin/gij). findjava will return, what is specified. I really hope that gij and sablevm will add a java-config file for their wqrappers and not for the main app. One thing needed is to put such a (minimal) standard of command-line arguments in the Java policy, so JVM packagers not what to implement. I'm not sure if we got there yet. IMO we are there now. But lets see what other people thing what needs to be included in this list. The internal (GC, jit and so on) are handled by findjava, debuging options are better handled on a per JVM basis as well and this should probably be done via either a findjava switch or a via using 'OVERWRITE_VM_COMMAND' (or whatever it was...), so you exactly know which VM is called. So the only uscase is starting a app and there it's enough to use CLASSPATH and the main class. Ean wrote: Nope, me wrote that :) It's true that we cannot handle every option. But we can handle them progressively as the need appears. Whether or not Sun should do it, Yes, also true, but IMO just *now* there isn't any other situation, which isn't handled by teh wrapper scripts and all other commands. nothing prevents us from making our own standard if needed (ie if Sun compatible is not enough). ^^ :) Sun isn't compatible to each release, which I learned during the discussion and why I had to stop using teh alternative system altogether... between JVM callers and JVMs. For Sun JVM, the mpkg-j2sdk could install our own wrapper if necessary. True, but very confusing... I hope I represented well the opinions (obviously, complain if not) and that will help understanding the situation. I think you summariesed it really well! Thanks! Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hello Ricky, only to debian-java and not to the BTS? Wednesday, October 8, 2003, 11:55:23 AM, you wrote: I did the configuration by telling the user what PATH to set, but maybe this would be better done using the alternatives system (I wasn't thinking Debian-only at the time). Do you think this is worth writing again? IMO, this has the big drawback, of all alternative bases configurations, that the app can't be sure that the /usr/bin/java will be able to run the app. Even more: it can't even test for it, because 'out of packaging' JVM are also considered, which should not happen. [commandline compatible] obviously). findjava seems to fix problems with other JVMs that don't provide this, and I can't see any conflict here. findjava does not fix this, apart from internal switches, which enable certain fetaures like jitter (required for 'client') and server mode (something like 'longer startup, but fast during run'). The only thing it does is: * garantee that the outputted command is instaleld by the apckageing system * configure the javacommand with internal switches, so that some special, and requested, mode is used. Is there a JVM in existence that doesn't provide the standard 'java' wrapper (except Sun etc., where it isn't a wrapper, obviously)? AFAIK: no. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hello Ricky, Wednesday, October 8, 2003, 5:56:22 PM, you wrote: Well, if the Debian Java policy were modified so that the command line were rigorously defined (basically take the output of java -help from the Sun JVM or elsewhere) I'm waiting for the screams... Lets see: java -help will output something different beween almost all version. Let it be small changes in internal -X.. things or simple the -cp options, which is possible since sometimes back. Also, there isn't any guideline what for example '-classpath' includes. Is it with or without the core classes? The alternatives system works fine for sensible-editor, where you just specify a file on the sensible editor only has one thing to garantee: that sensible-editor file will open the file. The rest is interactive. /usr/bin/sendmail for example would be one app, which could be used as alternative (but for other reasons it cannot). awk has two implementors on debian. www-browser is again an interactive tool, which only garantees that 'www-browser http://adress/' work, nothing fancy as 'www-browser openURL(...)', which all the latest browser support. /usr/bin/java has to garantee even much more: that the commandlien interface is the same all over, that the JVM is able to run *all* code, which is thrown at it. OYu can't do that with the variety of JVMs, which are available on debian. For example all free JVMs lack the ability to run swing code or (AFAIR) the java-1.4 NIO code. I don't see why sensible-java, or just 'java' couldn't have a standard interface, with things like java -classpath BLAH -bootclasspath BLAH etc. Isn't that Becuas ethe altwernative system could garantee the 'backend', like core classes and so on. why Sun made the -X command line options, so that they could implement wierd options without worrying about breaking compatibility (because no-one relies on the -Xmx flag, right? :). This could sensible be implemented: if your app has the ability to run with some allocated memmory: add it to the 'SERVER' line and be happy about it. Or I will add a '--mem128' and '--mem256' option to findjava, which is using a 'MEM128' field in the java-config files. If findjava does stuff with apt-get or dpkg, then perhaps it should be more of a debugging tool, rather Please do me a favour: try the tool and read the manpages, which are in the 'new-java-policy' package, which is available from deb http://www.katzien.de/debian/java ./ - java-config-file(5) - findjava(1) - findjavarc(5) than something that happens every time a Java program is launched. Startup time for Java programs is already a contentious issue, especially for servers. And thats why findjava was asked for. AFAIK: no. This seems to negate some of the reasons you gave, other than 'a future VM might not do this'. All of them try, but there is no 'official' interface and there isn't any way to be *sure*, that this stays the 'standard interface of sun JVMs'. I would also be happy, if I could say: here, java has to take this arguments and it must resultin this-and-that. But this will be *really* confusing, when future sun java versions changes this interface. I should read the bug report and associated threads before writing further emails. Please also read the manpages and the included policy (in /usr/share/doc/new-java-policy/policy.txt.gz) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: java-common: New java policy including tools to manage the changes
Hello Ean, Wednesday, October 8, 2003, 6:22:49 AM, you wrote: I still don't understand what this achieves that alternatives do not. Imagine this situation: Application needs a special feature, which is implemented in about half the java alternatives. /usr/bin/java will be set by all java binaries and in this case, /usr/bin/java is set by a package, which does not implement the requirements. There is a second installed java package, which does implement it. - apt will see all dependencies fullfiled, app will call /usr/bin/java and will not run. The workaround would be to follow the symlinks, but that would be the working *around* teh alternative system *and* you would end up with the 'findjava' code in every starter script (as the fallback, when /usr/bin/java isn't working). You get a similar 'feature' with the /etc/findjavarc and 'PREFERRED_...' variable. There is nothing particularly special about Java that requires a more elaborate alternatives mechanism than any other interpreter. IMO there is. See the discussion in debian-java, where this was turned over and over again. If the wrapper script for each VM does its job properly then the classpath should get set to what it needs to be and the VM will be invoked with all the proper conventions. This isn't the problem at all. The problem is that some java VMs will be able to start something and others will not. It would seem to me that findjava will simply invoke whichever VM it Please read the manpage of findjava and how it is used. It does not invoke anything, it just outputs the 'java command' to stdout. It garantees, that this outputed command is available on this system. If you need more than this, you can still do some magic based on this. finds first in its list of VMs and that will be that. It loses the priority mechanism of the alternatives scheme and doesn't really add The priorites were also discusssed and the 'would be' consensus was, that we can't assign different priorities without having a big row. based on what facts will you assign priorities? And you could still end up in a situation, where a lower priority JVM will run a app, but a hiher priority JVM will not. that much that cannot be done with proper wrapper scripts for each VM. IMO for the basic function (starting a app with a classpath and a main class) it's already now enough. For more, you cannot specifiy it *enough* to satisfy every situation (like: enable the jitter with what option? Enable what GC with what option? What subset would you implement?) and IMO SUN should do this and not we. I may need to go back and read the earlier discussions more carefully but I never saw how the findjava script adds anything that cannot be achieved using the usual (and up til now sufficient) IMO the today mechanism is *not* sufficient. Have a look at the starterscripts of all big java papps how they find the java binary: all uses JAVA_HOME for it and /usr/bin/java as a fallback. Please read the script and what it does. Also there is a lot of mails about the 'alternatives are enough to find a java binary' discussion during the second edition of the proposal. Jan
Bug#212863: java-common: New java policy including tools to manage the changes
Hello T.,
Tuesday, October 7, 2003, 10:41:52 PM, you wrote:
1) Standardize the invocation interface, so that it is feasible to have
java packages that will have a hope of running on a VM that the
packager did not directly support.
The discussion has shown, that we can't standardisize this much more
than which is already done. This should have been done by sun or any
other body and I don't think that thjis is possible in a debian
policy.
I hope that all java binaries will implement the basic things like
name vm-specific-params -classpath jarfiles, seperated by ':'
mainclass app options
or react on a set CLASSPATH
This seems to be the case with all tested JVS (and using sablevm
wrapper). Everything else seems to be madness to try, because
everybody has a differenet opinion on where to stop and what would
be better.
2) Localize the invocation interface, so that the hunt-and-find-a-good-VM
logic isn't replicated in all the myriad java packages.
Yes.
This is all to make it easier on the packagers of end-user java programs,
not to make it easier for the VM, compiler, etc packagers.
Yes.
I think that you are right in your assessment of needing to submit a
patch to findjava whenever Kaffe's command line changes, and I agree that
No. Findjava will output the things, which kaffe specifies in its
/usr/share/java-config/kaffe file, nothing more. If a application
package chooses to play around with other options, it has to
implement the logic for this, based on the findjava output, and hope
that kaffe won't break it with the next version.
this is suboptimal. I also think it would be good to define a standard
interface that packages like Kaffe could support, but I do not think that
is sufficient, because we cannot hope to get Sun (or any of the other
proprietary vendors) to conform to that standard.
Thats exactly the point. With the findjava implementation it's easy
to do something like
# tests, if sablevm is used directly and not the wrapper.
isSableVM(){
if [ $1 = /usr/bin/sablevm ] ; then return 0 ; fi return 1;
}
PACKAGES=...
JAVACMD=$(findjava ...)
if isSableVM $JAVACMD ; then
CLASSPATH_OPTION=--classpath
else
CLASSPATH_OPTION=-classpath
fi
$JAVACMD $CLASSPATH_OPTION `java-config $PACKAGES` com.example.Main
Usually such logic won't be nessesary. The main usecase is looking
like this:
# package, which jars need to be on the classpath
DEPEND_LIST=package1 package2 package3
# Known working java binaries, which can run this package app.
WORKING_JAVA=kaffe gij sun
export CLASSPATH=$(java-config --all $DEPEND_LIST):app-main.jar
JAVACMD=$(findjava $WORKING_JAVA)
$JAVACMD com.example.Main
Thanks for the comments!
Jan
Bug#212863: java-common: New java policy including tools to manage the changes
Hello Ean, Tuesday, October 7, 2003, 9:38:20 PM, you wrote: I still don't like the findjava idea. What is the goal? The goal is to provide a search mechnism for the alternatives. The discussion in debian-java has shown, that the alternative machnism isn't enough and especial isn't reliable. findjava will be called with the list of the 'known working' java implementations and will either return one of them, which is installed or exit with an error code. This will ensure that the called java command is known to be working with your package. The basic equivalent of this code is for java in /usr/bin/kaffe /usr/lib/j2sdk1.4/bin/java ... ; do if [ -x $java ] ; then JAVACMD=$java break fi done Instead you do JAVACMD=$(findjava kaffe sun-java-1.4 ...) So the difference is: * The code is in one place - less bugs * Its abstracted by packaging names and not places, where the binary is - palces can change... * the java binary automatically get some parameter, which the java binary maintainer things usefull. * you can explicitly ask for a special kind of java binary (one, which is able to run in server mode), without putting much more logic into the startscript. It looks like this script provides a common interface to all of the java execution systems (compilers, JITs, interpreters or otherwise) It only provide an 'search mechanism' to the binary, which can execute java byte code. by concentrating shell script adapters into a single file. I think it is much more maintainable to define the calling conventions and then require each system (in the language of its choice) to provide a java file that provides the common calling convention. This is basicly, what the findjava mechnism does. With the findjava script it looks like I would need to submit a patch anytime Kaffe's command line conventions changed rather than just fixing an adaptor that resides in my own package. Nope, you will change the java-config file in the kaffe package, which specifies the java command. See the manpage of java-config-file(5) in the below package. You, as the maintainer of kaffe, will have the right and power to change, which kaffe command is called and with which parameter (in the basic run). You can also specify, how the kaffe binary should be started if the app should be run in server or client mode (if you know more interesting cases, I will implement them). Please have a look at the package available from deb http://www.katzien.de/debian/java ./ - new-java-policy package It includes java-config files examples (this files would be provided by the package containing the jars/java binary and not one single package) and the findjava sript and manpage. Please have a look at it and try it. Thanks for the comments! Jan
Re: Installing a Java VM on Debian
Hello Dj, Sunday, October 5, 2003, 1:13:52 PM, you wrote: I note when looking through the package lists that there quite a few GPL java environments available: First of all: Neither Blackdown and IBM JDK 1.1 are GPL. Both are 'sun derived' and under their license. Also, I'm fairly sure, that the IBM package is a installer and that this thing is useless, as the 1.1 Download isn't anymore on the servers. Also 1.1.8 is *really* outdated. If you want a recent 'sun derived' JDK, you probably want to use mpkg-j2sdk (- google or this ML) and a '*-bin' download from either Blackdown or IBM or Sun. Besides speed and performance, what is the difference between the above virtual machines, and is one better to use than another in terms of stability and being able to run pretty much any java app you throw at it. Tomcat is a pretty big app to throw at a JDK... GIJ is a interpreter, so no 'JustInTime compiling'. GCJ can compile your java code to native. Both aren't yet able to take *everything*, what the 'world is throwing at it'. Kaffe has a jitter, but also does not have all SUN API implemented. I'm not sure how far sablevm is. You probably want to search the net for some firsthand experiences with tomcat and the above free java virtual machines. Blackdown is a enchanced linux port of the sun VM. But the last debian packages are a little bit outdated (there are newer *-bin downloads). IBM does something similar with their 'IBM JDK'. I am also looking to install a JSP engine on the web server, either Resin or Tomcat depending on demand, and wish to know which would be the best VM to run with that also. JSP is tricky, as Tomcat uses either jikes or the internal compiler of a sun JDK to compile the JSPs into java code. Another problem is the things your clients will throw in as webapps. If you have the chance to test this beforehand then you can give the above free VMs a try. If you are not sure or if you know that there are ImageIO, NIO or AWT/Swing code in there, then you probably need a sun derived JDK. Tomcat will probably also need a JDK1.3 or above, so the IBM 1.1 is out. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing a Java VM on Debian
Hello Dj, Sunday, October 5, 2003, 1:13:52 PM, you wrote: I note when looking through the package lists that there quite a few GPL java environments available: First of all: Neither Blackdown and IBM JDK 1.1 are GPL. Both are 'sun derived' and under their license. Also, I'm fairly sure, that the IBM package is a installer and that this thing is useless, as the 1.1 Download isn't anymore on the servers. Also 1.1.8 is *really* outdated. If you want a recent 'sun derived' JDK, you probably want to use mpkg-j2sdk (- google or this ML) and a '*-bin' download from either Blackdown or IBM or Sun. Besides speed and performance, what is the difference between the above virtual machines, and is one better to use than another in terms of stability and being able to run pretty much any java app you throw at it. Tomcat is a pretty big app to throw at a JDK... GIJ is a interpreter, so no 'JustInTime compiling'. GCJ can compile your java code to native. Both aren't yet able to take *everything*, what the 'world is throwing at it'. Kaffe has a jitter, but also does not have all SUN API implemented. I'm not sure how far sablevm is. You probably want to search the net for some firsthand experiences with tomcat and the above free java virtual machines. Blackdown is a enchanced linux port of the sun VM. But the last debian packages are a little bit outdated (there are newer *-bin downloads). IBM does something similar with their 'IBM JDK'. I am also looking to install a JSP engine on the web server, either Resin or Tomcat depending on demand, and wish to know which would be the best VM to run with that also. JSP is tricky, as Tomcat uses either jikes or the internal compiler of a sun JDK to compile the JSPs into java code. Another problem is the things your clients will throw in as webapps. If you have the chance to test this beforehand then you can give the above free VMs a try. If you are not sure or if you know that there are ImageIO, NIO or AWT/Swing code in there, then you probably need a sun derived JDK. Tomcat will probably also need a JDK1.3 or above, so the IBM 1.1 is out. Jan
Re: Problem with compiling eclipse
Hallo DIEGO, * DIEGO ENRIQUE RODRIGUEZ DELGADO wrote: I have Debian Sid in SunBlade100, I compile the eclipse in this machines. Can you run eclipse, if you compile from source from the debian packages? apt-get source -b eclipse-sdk What is SunBlade100 actually names as a 'debian arch'? $./build -os linux -ws gtk the problem is when the eclipse can't execute bash: ./eclipse: cannot execute binary file Small wonder: the ant buildfile (this is, what you call via ./build.sh) does *not* build the binaries or the libswt *.so-files. So either you build them as well or you try the above debian packages, which do build from source. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scriptpackage for new java policy available
Hallo Jan, This is just a quick note, that I will be away during the next week, so I can't really do some bugfixing, if these will show up. I got one bug in the findjava script, which now should honor the user set env variables. The new packages are uploaded. Anyway, I will probably able to answere any other mail. I would be really happy if someone could give some comments on the scripts. * Jan Schulz wrote: [re-edit of another mail] Sorry about that. I was too lazy to CP, so I just re-edited a message and missed the headers :( Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Scriptpackage for new java policy available
Hallo,
I've uploaded a apt-get'able 'new-java-policy' package, which contains
all the related scripts and also some additional java-config files for
all 'lib.*-java' packages, which I had installed and for kaffe, gcj,
sablevm and sun-java-vm-1.4 (mpkg-j2sdk version I think).
This are basicly the scripts, which are also attached to
|Bug#212863: [PROPSAL] New java policy including tools to manage the changes
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212863)
which some additional debug Messages (enable via 'export DEBUG=yes')
in java-config.
The thing can be found at
deb[-src] http://www.katzien.de/debian/java ./
To play around, try
|findjava [--server|--client] kaffe gcj sun-java-vm-1.4 sablevm
|java-config [--all|--contrib|--classpath] package-name ...
I've taken the ant package and to show how 'CONTRIB' works and how
apps can use the java-config system. tomcat4 isn't done as properly.
There is also a dh_java script, which will allow for such things:
debian/package.jars:
|JARS=/usr/share/subdir/private.jar:#DEBHELPER#
|CONTRIB=ant
debian/package.java:
|libregex-java =2.5
|libother-java =4.5
This information will be included in debian/control as {java:Depends} and
the whole will be muched into a usr/share/java-config/package file:
|JARS=/usr/share/subdir/private.jar:/usr/share/java/package.jar
|CONTRIB=ant
|DEPENDS=libregex-java libother-java
Also, if CONTRIB is present, a postinst and postrm debhelper part will
be included.
See man dh_java for more info. Or read the script itself, it's my
first perl script...
Every script has a manpage and there are also manpages for the
configuration files:
java-config-update(1), dh_java(1), findjava(1), java-config(1),
findjavarc(5), java-config-file(5)
Any comments *greatly* apreciated!
Jan
signature.asc
Description: Digital signature
Re: Problem with compiling eclipse
Hallo DIEGO, * DIEGO ENRIQUE RODRIGUEZ DELGADO wrote: I have Debian Sid in SunBlade100, I compile the eclipse in this machines. Can you run eclipse, if you compile from source from the debian packages? apt-get source -b eclipse-sdk What is SunBlade100 actually names as a 'debian arch'? $./build -os linux -ws gtk the problem is when the eclipse can't execute bash: ./eclipse: cannot execute binary file Small wonder: the ant buildfile (this is, what you call via ./build.sh) does *not* build the binaries or the libswt *.so-files. So either you build them as well or you try the above debian packages, which do build from source. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: Scriptpackage for new java policy available
Hallo Jan, This is just a quick note, that I will be away during the next week, so I can't really do some bugfixing, if these will show up. I got one bug in the findjava script, which now should honor the user set env variables. The new packages are uploaded. Anyway, I will probably able to answere any other mail. I would be really happy if someone could give some comments on the scripts. * Jan Schulz wrote: [re-edit of another mail] Sorry about that. I was too lazy to CP, so I just re-edited a message and missed the headers :( Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: findjava requirement
Hallo Ben, I've sent already an answer to this mail, but it seems that it never got out... * Ben Burton wrote: If writing it in Perl means we're more confident in its correctness in all cases, I say let's do it. I have no idea about perl, so it's either my sh or someone elses perl :) After all, this is a script that will be used by *every* Java package. In this case it doesn't matter if it is written in sh or perl: The interface to the java startscripts will be the *output* (to stdout), not any array or env-variable. Neither perl nor sh will let you preserve 'words' there, it will all be one big string and the starter script will have the control if that gets broken into words or not (via quoting). Another thing is, how you actually would write up this arguments, that they are treated in that way. The only thing which comes to my mind is writing it in perl itself, so that the 'java-config files' will be includeable (or whatever accessable) from 'perl-findjava'. Another thing would be XML... To access this information would also mean that we have to write every starter script in perl, as otherwise we don't have a way to pass this information on. This would mean that a java maintainer has to learn perl before he can package a java app. Ok, I had to learn sh, but still... Anyway, all this is IMO overkill, as in most cases it will include some *very* simple arguments like '-server' or '-enable-jit' and in most cases (=default), it will simple drop only one 'word', which will be the java binary. I don't think that we have to worry about 'usr/bin/java command' (not the space in the file name...). There is already anought to make 'black magic' a little brighter, so I won't comment on that :) Oh, man bash has some nice para about it :) So, how are we going on from here? Should I start writing the bugreport against java-common? Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212863: [PROPSAL] New java policy including tools to manage the changes
retitle 212863 [PROPSAL] New java policy including tools to manage the changes thanks Hallo Stefan, * Stefan Gybas wrote: you (or anybody else) can't replace the whole Java Policy. I can't see, why not? You need to submit individual proposals for the individual changes (e.g. the naming of JARs in /usr/share/java or the use of your tools) I think that breaking this proposal into small changes doesn't make sense. More or less, it tries to change the way in which java packagess are made. I understand, that the main debian policy is a a document, which enforces 'common practise'. IMO, the debian java policy is different, as it is a document, which describes some rules, which are only usefull, if all packages agree on them (like the virtual packages now or the scipts in the proposal) and implement them. It's not a ammendment but a replacement, as IMO the old policy does not work properly. It also tries to fill most of the holes, which the old policy left open (see the 'quetions' section). I don't expect to have this changes implemented before sarge is released. and you need people (strictly speaking Debian developers) who second your proposals. Just Yes, thats why I sent this bugreport. Sorry, that it wasn't titled properly. package). Please remember, we don't have the constitutional power to force other Debian developers to implement the specification. Changes can only be made if (most of) the people that have to implement it agree. That's exactly, why I'm sending this now as a PROPOSAL to the java-common pakage: to get the feedback if this changes are acceptable. [scripts] I can include these in the java-common package but I will not replace the Java Policy. These scripts need to prove their usability first before they can be made mandatory. Yes, I understood that. They are not meant as the 'last word', but I also wanted them to get a broader audiance. I will add wishlist bugs to the JVM packages and try to get a patch into mpkg-j2sdk, so that they can be started to use in packaging scripts and bootstrap scripts. Thanks for the feedback! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: findjava requirement
Hallo Ben, * Ben Burton wrote: On the other hand, Perl deals with things like quoting and other problems resulting from unanticipated command-line arguments somewhat better than sh does (e.g., you can start the JVM by passing its command-line arguments as an array, not by some piece of sh black magic that gets the quotes right and separates arguments - some of which may contain spaces - at exactly the right places [1]). [1] Perhaps you can do this in sh too and I just don't know how. Regardless, I stand by the point made in the second paragraph. aehm :) Bash (that's what it is written in currently. But I guess, that plain sh isn't different here) will seperate all 'words' in your commandline, if you don't quote them. Words in this case means, everything, which is seperated by one of the chars in $IFS. So, if you don't want to have your things seperated, either set $IFS correctly (for you case) or make sure that around your things are a quote. I tiped into that one, while I was rewriting the splash screen mechanism in eclipse. It needed 'command argument' as one option, as in eclipse ... -splash 'command argument' ... Anyway, it doesn't matter at all, as we can't use it when we don't want to have the requirement that *all* starter scripts have to be written in perl. findjava is use as in JAVACMD=$(findjava ...), so the *output* of the script is relevant and you can't preserve 'words' in this case. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: findjava requirement
Hallo Ben, I've sent already an answer to this mail, but it seems that it never got out... * Ben Burton wrote: If writing it in Perl means we're more confident in its correctness in all cases, I say let's do it. I have no idea about perl, so it's either my sh or someone elses perl :) After all, this is a script that will be used by *every* Java package. In this case it doesn't matter if it is written in sh or perl: The interface to the java startscripts will be the *output* (to stdout), not any array or env-variable. Neither perl nor sh will let you preserve 'words' there, it will all be one big string and the starter script will have the control if that gets broken into words or not (via quoting). Another thing is, how you actually would write up this arguments, that they are treated in that way. The only thing which comes to my mind is writing it in perl itself, so that the 'java-config files' will be includeable (or whatever accessable) from 'perl-findjava'. Another thing would be XML... To access this information would also mean that we have to write every starter script in perl, as otherwise we don't have a way to pass this information on. This would mean that a java maintainer has to learn perl before he can package a java app. Ok, I had to learn sh, but still... Anyway, all this is IMO overkill, as in most cases it will include some *very* simple arguments like '-server' or '-enable-jit' and in most cases (=default), it will simple drop only one 'word', which will be the java binary. I don't think that we have to worry about 'usr/bin/java command' (not the space in the file name...). There is already anought to make 'black magic' a little brighter, so I won't comment on that :) Oh, man bash has some nice para about it :) So, how are we going on from here? Should I start writing the bugreport against java-common? Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Bug#212863: [PROPSAL] New java policy including tools to manage the changes
retitle 212863 [PROPSAL] New java policy including tools to manage the changes thanks Hallo Stefan, * Stefan Gybas wrote: you (or anybody else) can't replace the whole Java Policy. I can't see, why not? You need to submit individual proposals for the individual changes (e.g. the naming of JARs in /usr/share/java or the use of your tools) I think that breaking this proposal into small changes doesn't make sense. More or less, it tries to change the way in which java packagess are made. I understand, that the main debian policy is a a document, which enforces 'common practise'. IMO, the debian java policy is different, as it is a document, which describes some rules, which are only usefull, if all packages agree on them (like the virtual packages now or the scipts in the proposal) and implement them. It's not a ammendment but a replacement, as IMO the old policy does not work properly. It also tries to fill most of the holes, which the old policy left open (see the 'quetions' section). I don't expect to have this changes implemented before sarge is released. and you need people (strictly speaking Debian developers) who second your proposals. Just Yes, thats why I sent this bugreport. Sorry, that it wasn't titled properly. package). Please remember, we don't have the constitutional power to force other Debian developers to implement the specification. Changes can only be made if (most of) the people that have to implement it agree. That's exactly, why I'm sending this now as a PROPOSAL to the java-common pakage: to get the feedback if this changes are acceptable. [scripts] I can include these in the java-common package but I will not replace the Java Policy. These scripts need to prove their usability first before they can be made mandatory. Yes, I understood that. They are not meant as the 'last word', but I also wanted them to get a broader audiance. I will add wishlist bugs to the JVM packages and try to get a patch into mpkg-j2sdk, so that they can be started to use in packaging scripts and bootstrap scripts. Thanks for the feedback! Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: findjava requirement
Hallo Ben, I have no idea, *when* my mail will arrive at the list (the last mails took four days each :( ), but anyway... * Ben Burton wrote: Right. So when you have single command-line arguments that could contain spaces and/or quotes, things can become very hairy very quickly. Yes. Bot are not needed for findjava or java-config... Okay. Having not had a chance to look at the scripts yet, I thought the args to the java app were being passed to findjava. If findjava will only ever be given a small number of arguments whose values we already know then this is less problematic. findjava will take '-client' and '-server' just now. The rest will be package names, which do not allow any of the 'funny' characters. I'm ready with all but 'man 5 java-config-file', which I will do in a minute. I will then upload everything to a bugreport to java-common. There is also a first version of dh_java, which will do almost all jobs, required by the proposed policy. Learning perl is fun as well :) At least if you can do CP all over... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: findjava requirement
Hallo Ean, * Ean Schuessler wrote: For instance, I can now set JAVA_HOME on my machine to /usr/lib/kaffe and run the standard startup scripts for Catalina, JBoss or OFBiz and they will make a real attempt to run. Of course, there are still shortfalls in the base class libraries but that is a different problem. But they *wont* run. It's not the problem about java.home or not. The problem is, that you can't use the alternative system to get the JVM. Apps rely on: JAVA_HOME set, so that: * they can get $JAVA_HOME/bin/java (lost of bootstrap scripts) * Using java.home/bin/something to do some work (ant) Thats why I have put this special cases, which I found usefull in the light of debian packaging (- running and building) into the proposal. The new policy will require that there is a bin/java script and, if the package includes a 'ant-environment', includes and bin/javadoc. It also needs to set the build.compiler. This will allow us to use this as JVM and compile environment. It still needs. in some cases, some logic in the scripts to make up for the different implementations. This is IMO still better than taking the pain to make up a policy, which tells everybody, that bin/java should accept '-classpath' and how to deal with it or which '-X...' switches should be present. As I already said, this isn't the main problem with a alternative managed JVM. The big problem there is the difference between different implementations: /usr/bin/java means that I can't know, what is actually implemented in this VM. Are the XML APIs present, is javax.swing.*.Spinner included? 'assert' or java NIO? Even if you add versioned bin/java-version *only* for the 'sun-derived' VMs, you end up with one java for each version (sun java 1.4.*2* AFAIK introduced some new classes), as the discussion up to the 4th proposal showed. non-standard. The /usr/lib/sablevm/jre/bin/java script should do whatever is necessary to adapt the standard Java commandline options to SableVM's. Please note, that there isn't any 'standard java commandline option'. Take for example the '-cp' option for javac. This should be implemented in the latest sun JVM. It isn't anywhere else. There are breaking changes inbetween versions. Which version do you want to implement in the policy? It seems to me that findjava is trying to merge all of the VM adapter scripts into a single large script. That looks broken to me both in terms of introducing unnecessary dependencies and creating maintenance headaches for all of the VM maintainers. Please have a look at the discription, which I posted somewhere in this list. It describes *what* findjava does (its also in the source of findjava in a big comment on the top). There are also some posts, *why* it does this. In short, it makes it posisible to use different VMs and let the user interact with that. There are two different levels of interaction: 'Overwrite' and 'prefered'. Overwrite will make findjava *always* return one JVM. This is for testing, or if one wants to use a VM outside of the packaging system. Prefered will let you specifiy one VM, which should be used, if the package maintainer of the app has already tested this VM and found it acceptable to run the app. Another pro (IMO) is, that you have to deal with package names and not with binary names. This will make it possible to change path in case of upstream renaming (like /usr/lib/kaffe - /usr/lib/kaffe1.2) without rendering all other packages unusable. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: findjava requirement
Hallo Ean, * Ean Schuessler wrote: After having this discussion, because they are not 'similar enough' to rely on the alternative system. Well, they *could be* similar enough if we specify exactly what Debian expects a JAVA_HOME setup to provide. It's not the java.home or anything else. That's only important for apps like ant, which rely on java.home/bin/javadoc and such thing. The problems are: * different commandline option. Try -Xm256mb or the JIT options with different VMs... * different API level: are the XML/whatever APIs available with every VM? * is this special feature actually implemented? Read the mails from proposal one to three, where this was discussed and the conclusion was, that you can't even rely on sun derived VMs to be that similar, that it works. The problem is, that you also can't version this things: virtual packages don't have versions, and if you need a new virtual package or bin/java-version every time, you end up with hundreds... The packages of those special VMs would need to provide wrappers that adapt their behavior to the Debian JAVA_HOME standard. Also, the 'JAVA_HOME standard' does not exist, as the only thing which defined it is the sun layout. And even IBM does it diffrently with 'put all jni headers into $JAVA_HOME/include'. Consider: kaffe, sunVM, sablevm and gij. User has installed kaffe and gij, the alternative system has put gij as /usr/bin/java. App runs on kaffe and sunVM. App calls /usr/bin/java (or /usr/lib/jre/bin/java). Crash... Tell me again how findjava fixes that problem? The fix is more that you don't call any alternative managed app, but the VM directly. for vm in /usr/bin/kaffe /usr/lib/j2sdk/1.4/bin/java ... ; do if [ -x $vm ] JAVACMD=$vm break fi done if [ ! -x $vm ] echo No Java Virtual Maschine found, abort... exit 1 fi findjava takes this aproach and puts a level of abstraction inbetween (the package names of the VM) and factors this code into one place: the findjava script. It also makes it possible to choose one default VM, which should be used, if this VM is 'known working'. For more information, please read the discussion from the 3 Proposal up to now, which helds all the arguments about this. Also, the implementation is at www.katzien.de/debian/java/. Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
