I use 2 systems, both with ant on them. On the first system ant built fine. On the second it would fail with JAVA_HOME not found (even though it was there in profile.env). The problem was that the ebuild was trying to set it's own JAVA_HOME using the JDK_HOME environment variable. This variable did not exist on the problem system. Exporting JDK_HOME to the same setting as JAVA_HOME allowed the build to complete. Maybe some changes are needed to the ebuild process of ant.
I had the same problem although i'm using the blackdown version of java. Anyways it required me to set JDK to the blackdown jdk which is separate from the blackdown jre which is why the ant ebuild operates the way it does.
I am using the blackdown jdk also. The jre also exists on my system (hmmm). Anyway, the build shouldnt use my JAVA_HOME variable if it's set to use the jre since the build needs jdk. Although I assume anyone who does java development would have the jdk instead of the jre for sure. Regardless, maybe the ebuild should require the jdk and not blindly try to use the jre.
I'm glad I'm not the only one upset by rude programmers overwriting my environment variables willy-nilly. I'd like ot sugest the following change: OLD: src_compile() { export JAVA_HOME=${JDK_HOME} ... NEW: src_compile() { if [ -z "$JAVA_HOME" -a -n "$JDK_HOME" ]; then export JAVA_HOME=${JDK_HOME}; else die "Please set JAVA_HOME OR JDK_HOME somewhere." fi ... I recommend that "somewhere" be replaced by "make.conf", "in this shell", or whatever seems best.
We are aware of the env var hassles that exist currently. The problem is that some ebuilds can compile and run nicely with only the JRE, others require the full JDK. Currently, we cannot assume that the DEPEND/RDEPEND statements do what we want; we cannot depend on blackdown-jdk and assume it will be used as the VM, as the user may configure his system VM completely differently. Thus, we need an extra level of dependencies, one where the ebuild can say "I'll work with either a JRE or a JDK, just set up some standard env vars, and I'll be good", or it should be able to say "I can only work with an 1.4.x JRE/JDK, please provide that". It's on the plate, but we'll have to finish the potatoes first.
While I'm not 'upset' about this, I was reporting a problem that may occur on some systems (it didn't happen on my home systems...hmm). Since the developers (who do a damn good job and have never been rude to me) are aware of this potential problem I'll close it myself in hopes that they'll work it out eventually. Keep up the good work guys, I'll keep the bugs comming. -Paul
