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
