Re: [PROPOSAL] dh_ant
Hallo Stefan,
* Stefan Gybas wrote:
>>I've had a look at this bug and I thing we should not fource a
>>specific javac or java at our users. If they don't want to download a
>>BD JDK, then this should be made possible.
>It is just for building the package. I don't think that most users will
>rebuild the Java packages, especially since they are architecture
I'm doing it all the time: I'm running woody and I have specified
deb ... stable
deb-src ... unstable
So I'm backporting all packages, which I want a nrwer version as in
woody.
>independent. You also need a lot of -dev packages (and gcc) for
>rebuilding C and C++ packages, so that's the normal way.
Yes, I know. But thats the same with java apckages (instead of -dev
you have the original jars and instead of different gcc versions, you
have javac1.3 and 1.4). And IBM javac *should* be the same as BD,
eclipse.org (jdtc), jikes or sun. If not, its a bug.
>>IMO java on debian needs some helper programms:
>This is surely useful for running the packages, but doesn't gain
>anything when you want to build the package. I think the package
>maintainer knows best which JDK is suited for building the package, so
>he should chose one.
Yes, (s)he should. *But* I know that I need a full JDK (meaning that
kaffe or any other 'free' JVM probably doesn't work), version >1.3.
So IMO I should be able to compile and run it with either IBM, Sun or
BD. Especially, I don't find it usefull to stick to 1.3 JDKs (which
would have been the resolution to the mentioned eclipse bug), when
everything else is 1.4 (later, better, faster, whatever :) on my
system.
>>* A skript which installs *any* jdk/jre-bin properly (mpkg-j2sdk is a
>> start, but it doesn't work with IBM SDK1.4), including
>> mozilla-plugins and so on. This should be properly advertiesed in
>> FAQ, README, Mozilla Maintainer, etc
>I think such a script should be put in java-common. Who wants to write
>one? :-)
google mpkg-j2sdk :) Was even mentioned in this ML few weeks back.
It's not perfect, but it puts the BD-bin and Sun-bin into the right
palce and 'Provides:' the right packages.
Yes, I also thing that it should be tighly coupled with java-common.
>>* A system to get a classpath at runtime, similar to shlibs files at
>> compiletime (if I haven't understood something wrong there).
>This will not be easy, for example when there are conflicting versions
>of one package, like log4j: Your package might use log4j 1.2 but also
>depend on another library package which uses log4j 1.1 - how do you want
>to resolve this situation?
liblog4j1.2-java and liblog4j1.1-java. Just like it's done with c
libs. Wasn't that exactly the problem which caused al the
libsomething<number> renaming of all the c(++) libs. If that's poluting
the debian, we should keep track of such packages and start removing
them, when they are not anymore needed. Should be easy with a skript
(search for lib*-java and check if it is in any Depends line...).
If API breakage is a problem, this should be in upstream README or it
can be asked upstream directly.
For the shlibs-like thingie:
I needed a mechanism to make two different versions of SWT working with
eclipse or other programms base don swt (I haven't seen any yet,
though). The problem was, that the gtk version of swt comes with two
jars, motif with only one jar.
To make this working with update-alternatives I came up with a file,
which specifes which jars should be included in the Classpath (and a
additionally varible to be used in elipse). Here is the content of the
file and also hwo it should be used:
/usr/share/eclipse/ws/libswt2.1-gtk2-java.jars
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
JARS=/usr/share/java/swt2.1-gtk.jar:/usr/share/java/swt-pi2.1.jar
# JARS=/usr/share/java/swt2.1-motif.jar # in the other one...
# Used for eclipse
WS="-ws gtk"
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
README:
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
if [ -r /usr/share/eclipse/ws/libswt2.1-java.jars ] ; then
# Will provide a variable named JARS, which can be appended to the
# CLASSPATH
. /usr/share/eclipse/ws/libswt2.1-java.jars
fi
CLASSPATH=$CLASSPATH:$JARS
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
libswt2.1-java is a virtual package (libswt2.1-ghtk2-java and -motif-
the real packages), which is provided by both packages and the
'libswt2.1-java.jars' file is managed by u-a.
There are probably better ways to do this, but IMO such a system could
be used to implement a sript, which can return a proper Classpath, if
the all package names are specified (one way) or a 'contributed to'
name (other way, like ant needs it). Also if App depends on lib a
which depends on lib b, lib b could be automagically added to
classpath of App.
That way we have at least one level of abstraction inbetwen.
But the main thing is to treat java libs the same way as c libs, with
versioned package names.
>I think it's still the best solution if the maintainers of Java
>applications hard-code the class path in their startup scripts (or use
>something line /usr/share/ant/lib). Sure, that's more maintenance work
>but it's the only way that I currently see to guarantee a sane class path.
The above could be automated with a "dh_javaclasspath" debhelper:
* parse Depends: for java libs -> add the Package names to a varible,
which is then recursivly added to classpath at runtime.
* provide the 'jars' file for this package.
(* even parse all java files for includes and check in which jars this
classes are (would need handling of reflection though...))
If we ar going to make java packaging easier, we should make this and
all the rest (startscripts) as easy as other packages are.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: