Re: [PROPOSAL] dh_ant
Jan Schulz wrote:
I'm doing it all the time: I'm running woody and I have specified
deb ... stable
deb-src ... unstable
You are a package manager, not a "standard" user. You should have a lot
of differnt JDK installed anyway to be ably to very bug reports so
what's the problem with on specific JDK in build dependencies?
So I'm backporting all packages, which I want a nrwer version as in
woody.
There's no need to backport (pure) java packages, I have tomcat4 with
all its dependecies from sid running fine on woody.
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.
They are not. Have a lot of fun filing all those bug reports, I have
given up and use what upstream uses.
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.
For example libpgjava will build a different driver when building with
JDK 1.3 (JDBC 2.0) or JDK 1.4 (JDBC 2.0 with standard externsions). The
same is true for Tomcat4, it will enable addition features when built
using JDK 1.4.
If you are absolutely sure that you gat the same results with JDK 1.3
and JDK 1.4 you can use either. But why wasting your time with bug
reports like "upstream works, Debian package does not" when you can
simply use the same setup as upstream does?
google mpkg-j2sdk :) Was even mentioned in this ML few weeks back.
I know, I even have it installed. But you said it was not working with
IBM's JDK so I was looking for a better alternative. If you want the
standard mpkg-j2sdk in java-common please file a bug report.
liblog4j1.2-java and liblog4j1.1-java.
What happens when they are both included in the class path like in the
scenario that I have described in my previous mail?
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).
Good idea. Let's see how well this works for other packages like JAXP
compliant XML parsers. Do you have time to test this?
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.
Again, what do you want to do when you need to add two conflicting JARs?
That way we have at least one level of abstraction inbetwen.
... without the infrastructure (ldconfig, dpkg-shlibdeps, ...) but the
the same problems as C libraries (conflicting libraries linked in one
application).
Stefan
Reply to: