Hi James, I've noticed that many of the Java ports you've worked on compile the Jar files newly. Is there any reason to do this? I like the fact that using the supplied jar files from a distribution are guaranteed to work. The reason I am asking is because with the upgrade to junit 4.4, commons-logging doesn't compile. compile.tests: [javac] Compiling 30 source files to /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/target/tests [javac] /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/src/test/org/apache/commons/logging/AbstractLogTest.java:20: package junit.framework does not exist [javac] import junit.framework.TestCase; Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to compile it, so for that port, I had to disable compilation and just use the supplied jar's, which I'm happy to do. The only reason I see to compile a Java port is if you are patching the source code. Regards, Blair
Blair Zajac wrote:
Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to compile it, so for that port, I had to disable compilation and just use the supplied jar's, which I'm happy to do.
The only reason I see to compile a Java port is if you are patching the source code.
Isn't running the supplied jar just like running the supplied binary ? Seems more like a question of binary blob versus open source to me... Then again, a working binary might be better than a broken source :-) (depending on who you ask, other projects like JPackage* recompile all) --anders * see http://www.jpackage.org/jpprequest.php
Anders F Björklund wrote:
Blair Zajac wrote:
Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to compile it, so for that port, I had to disable compilation and just use the supplied jar's, which I'm happy to do.
The only reason I see to compile a Java port is if you are patching the source code.
Isn't running the supplied jar just like running the supplied binary ? Seems more like a question of binary blob versus open source to me...
Then again, a working binary might be better than a broken source :-) (depending on who you ask, other projects like JPackage* recompile all)
--anders
I don't think the comparison with binary packages is entirely fair. Jar files fall in between source packages and complete binary ones. You can relocate a jar file without it breaking, but you can't relocate a binary package with dylibs, say if you want to move /opt/local into /Users/blair/my-macports. You have to recompile. There's also too many customizations people like to do with source releases, look at all our variants. You don't find many variants in Java packages. And I think saying "open source" is just mixing different concepts in this discussion. Right now compiling Java packages is more of a pain than it needs to be. This is the second package I've had to patch. Spring doesn't compile at all on 10.x unless you want to install JDK 6 which isn't officially released. Now commons-logging doesn't compile since it doesn't work with the new junit. Blair
Blair Zajac wrote:
The only reason I see to compile a Java port is if you are patching the source code. Isn't running the supplied jar just like running the supplied binary ? Seems more like a question of binary blob versus open source to me...
I don't think the comparison with binary packages is entirely fair. Jar files fall in between source packages and complete binary ones. You can relocate a jar file without it breaking, but you can't relocate a binary package with dylibs, say if you want to move /opt/local into /Users/blair/my-macports. You have to recompile. There's also too many customizations people like to do with source releases, look at all our variants. You don't find many variants in Java packages.
But just because they're relocatable and not many want to customize, doesn't make them not binary ? We are talking about regular .jar files with .class code here, right - and not .zip cousins with .java source, or something ?
And I think saying "open source" is just mixing different concepts in this discussion.
I might have misunderstood the original suggestion, I thought it said something like "why bother compiling the source when using the binary works better" ? Didn't mean to introduce a difference concept... --anders
participants (2)
-
Anders F Björklund
-
Blair Zajac