Hallo Arnaud,
* Arnaud Vandyck wrote:
>Can you give me some more explanations (private or on the list).
Here we go... I think you ar eon the list, so no private reply.
>> * Jan Schulz wrote:
>> ** getclasspath.sh
This script will be used in any java applications startscript. You (or
a dh_java) put the dependencies (package names) as param and it will
give you the complete classpath based on the Depends.
Currently the 'work' to figure out the classpath is on the applications
side: The autor of the startscript will have to set the classpath
according to the 'well documented classpath' (java policy). This
essential means, that you have to read every README.Debian of every
package, you depend on *and* of every package, this package depends
on... With this script, you put much of the work to the person, who
knows the classpath best: the maintainer of the library package.
Another pro is, that you can depend on different implementations of a
specific java API and the reason why I came up with such a thing
in eclipse. Applications, which have a UI based on SWT need to set
the classpath either to the gtk *or* the motif version of swt.jar. The
problem with this is, that the gtk 'swt.jar' is seperated into two
parts: the actuall swt implementation and the JNI glue (license
issue...). I could be possible, that the next version will have three
jars. Motif on the other hand has all its java code in one jar.
-> update-alternative can't handle this AFAIK. With the proposed
solution, it would be the 'description' file, which would be under
u-a (it is in the case of libswt*). Same could happen for
xerces-compatible xml parsers.
Packages, which depends only on a version of swt, can depend on
libswt2.1-java and get the classpath from the u-a managed value.
For the 'contrib' use: ant currently uses a complete dir for its
'tasks'. There are other apps, which use such plugin like mechanism.
For every such app, you need another dir. With the 'contrib'
mechanism, you only let the plugins 'contribute_to' the application
package. All such application then should ask for the 'conributed'
classpath as well.
>> ** update_javaclasspath.sh
Used to update the 'contrib' classpaths, so that it doesn't need to be
computet on runtime.
I would like to get this into the java-common package, together with a
script, which gives me a proper java to execute my code and other
helper scripts like mpkg-j2sdk, javaselect (or just depend on them).
Currently, using java, isn't really as easy as everything else in
debian is. The first thing is getting a JVM: go to sun, DL and what
now? Then you want java browser plugins working: mozilla is gcc 3.2
and java isn't (or the reverse...)
This could be helped, when we have this helper scripts (install with
mkpg-j2sdk, get the java.bin from a generic mechnism, which know about
all so installed jdk/jre).
For specific versions, such a script should include params to get only
1.4 compatible versions (or other...). It would also be nice, if we
would have virtual packages, which are more specific than
'java2-runtime' or 'java2-compiler'.
Same goes for the java browser plugin, which should get a 'c102', when
compiled with gcc3.2 and be seperated out by mpkg-j2sdk.
Together with policy changes, this would help to make using java
software as easy as everything else under debian.
Another thing is then to write a compile time infrastructure, like
* using ant in the same way as make -> dh_ant dh_make template
* compute the Depends: lines or at least make this easier (like
specify it once and use everywhere...) -> dh_java
* ...
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]
