When I try to emerge bsf, the compile fails, as the servlet-api.jar is not in it's classpath (at least, it looks like that's the problem). On looking at the ebuild, it has a rather discouraging: # karltk: this is dirty. should be fixed when we overhaul tomcat # and the entire servlet/java server pages system export CLASSPATH=${CLASSPATH}:/opt/tomcat/common/lib/servlet-api.jar export CLASSPATH=${CLASSPATH}:/opt/tomcat/common/lib/jsp-api.jar and it appears at least on my box that not only is it dirty but it also doesn't work. Both those files do exist on my box, and an echo $CLASSPATH after those two exports reports: .:/opt/tomcat/common/lib/servlet-api.jar:/opt/tomcat/common/lib/jsp-api.jar not that it matters (at least I don't *think* it does), but I'm using tomcat 5.0.18. Reproducible: Always Steps to Reproduce: emerge bsf (I have jython 2.1-r2, rhino 1.5-r5, tomcat 5.0.18 installed - all at current versions, and am building with Sun JDK 1.4.2.04) - any more information available on request Buildfile: build.xml init: prepare: bsf_debug-compile: [echo] Target: bsf_debug - Compile ... init: prepare: compile: [javac] Compiling 9 source files to /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/bsf_debug/build/classes [jar] Building jar: /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/bsf_debug/build/lib/bsf_debug.jar bsf-compile: [echo] Target: bsf - Compile ... init: prepare: checkDependencies: checkJacl: [echo] Warning: Jacl dependencies were not resolved. checkJPython: [echo] Warning: JPython dependencies were not resolved. checkJython: [echo] Warning: Jython dependencies were not resolved. checkNetRexx: [echo] Warning: NetRexx dependencies were not resolved. checkRhino: [echo] Warning: Rhino dependencies were not resolved. checkXalan: compile: [javac] Compiling 15 source files to /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/bsf/build/classes [javac] Note: /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/bsf/src/org/apache/bsf/util/JavaUtils.java uses or overrides a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/bsf/build/lib/bsf_core.jar jsdb-compile: [echo] Target: jsdb - Compile ... init: prepare: compile: [javac] Compiling 3 source files to /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/jsdb/build/classes [jar] Building jar: /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/jsdb/build/lib/bsf_jsdb.jar taglib-compile: [echo] Target: taglib - Compile ... prepare: compile: [javac] Compiling 2 source files to /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/build/classes [javac] /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/taglib/src/org/apache/taglibs/bsf/expression.java:56: package javax.servlet.http does not exist [javac] import javax.servlet.http.HttpServletRequest; [javac] ^ [javac] /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/taglib/src/org/apache/taglibs/bsf/expression.java:57: package javax.servlet.jsp.tagext does not exist [javac] import javax.servlet.jsp.tagext.BodyContent; [javac] ^ [javac] /var/tmp/portage/bsf-2.3.0/work/bsf-2.3.0/src/taglib/src/org/apache/taglibs/bsf/expression.java:58: package javax.servlet.jsp.tagext does not exist [javac] import javax.servlet.jsp.tagext.BodyTag; (After which it's clear that the compile is never going to succeed... Interesting btw, that neither rhino nor jython were detected, though both are installed?)
Just like to say that I'm clearly being an ingrate (looking at quite how many ebuilds KarkTK has added) but I'm keen to test groovy (depends bsf), and it's a pity that I can't quite get there yet... So Karl, keep up the good work! (Yes, I know this shouldn't go in a bug report, but all the same, there should be a mixture of stuff to cheer and depress in one's day...)
Maxwell, I believe the problem _is_ trying to build against Tomcat 5.0. In Tomcat 5.0, the javax.servlet.jsp and javax.servlet.jsp.tagext packages have been removed. (They were in Tomcat 4.x.) According to the Jakarta Apache Tomcat website, Tomcat 5.0 implements JSP 2.0 instead of JSP 1.2. I will have to research the impact of this, but clearly it will require a different import statement and perhaps additional changes to bsf-2.3.0. Please also refer to bug #55934, which I encountered using Rhino-1.5_rc5. I am posting patches to get past that problem there.
Part of Comment #2 is incorrect. Please ignore the first paragraph. I believe the problem in my case (using blackdown-jdk-1.4.2_rc1) was that CLASSPATH was not set, as shown by "java-config -P blackdown-jdk-1.4.2_rc1" I switched to blackdown-jdk-1.4.1, which had CLASSPATH set and the compile was successful. (I don't know why CLASSPATH wasn't set in blackdown-jdk-1.4.2_rc1.) Based on the warnings Maxwell shows, i.e., "Warning: * dependencies were not resolved." for various packages, I believe that Maxwell's CLASSPATH wasn't set properly in a fashion similar to my experience. Refer to bug #55934 for the patches I needed to be compatible with Rhino_1.5_rc5.
Under my version of java, I get the following: max@utopia max $ java-config -P sun-jdk-1.4.2.04 export JDK_HOME=/opt/sun-jdk-1.4.2.04 export JAVAC=/opt/sun-jdk-1.4.2.04/bin/javac export PATH=/opt/sun-jdk-1.4.2.04/bin:/opt/sun-jdk-1.4.2.04/jre/bin:/opt/sun-jdk-1.4.2.04/jre/javaws:${PATH} export MANPATH=${MANPATH}:/opt/sun-jdk-1.4.2.04/man export JAVA_HOME=/opt/sun-jdk-1.4.2.04 In that case, what am I supposed to set the CLASSPATH to?
Re: Comment #4: Maxwell, for blackdown-jdk-1.4.1, I have the following line: export CLASSPATH=/opt/blackdown-jdk-1.4.1/jre/lib/rt.jar:. I would suggest you try the equivalent for sun-jdk-1.4.2.04, which would be: export CLASSPATH=/opt/sun-jdk-1.4.2.04/jre/lib/rt.jar:. _assuming_ the rt.jar file above exists. If it doesn't, then see if you can find rt.jar in a similar directory. (This is just a guess, since I don't fully understand CLASSPATH. For example, I don't understand _why_ it is set on my system for blackdown-jdk-1.4.1, but _not_ for blackdown-jdk-1.4.2_rc1. I'm going to have to learn more about CLASSPATH, etc., as I try to use groovy. So maybe this subject will become clear to me after some study.)
I'm now starting to think the problem is a bug with the way java packages are added to the classpath - to whit: utopia max # java-config --list-available-packages [ant] Java-based build tool similar to 'make' that uses XML configuration files. (/usr/share/ant/package.env) [classworlds] "" (/usr/share/classworlds/package.env) [junit] "" (/usr/share/junit/package.env) [log4j] A low-overhead robust logging package for Java (/usr/share/log4j/package.env) [rhino] Rhino is an open-source implementation of JavaScript written entirely in Java. It is typically embedded into Java applications to provide scripting to end users (/usr/share/rhino/package.env) [commons-cli] The CLI library provides a simple and easy to use API for working with the command line arguments and options. (/usr/share/commons-cli/package.env) [jython] "" (/usr/share/jython/package.env) [pdflib] "" (/usr/share/pdflib/package.env) [tomcat] "" (/usr/share/tomcat/package.env) [xerces] The next generation of high performance, fully compliant XML parsers in the Apache Xerces family (/usr/share/xerces/package.env) utopia max # java-config -A tomcat,jython System classpath set You may want to update your enviroment by running: "/usr/sbin/env-update && source /etc/profile" utopia max # /usr/sbin/env-update * Caching service dependencies... utopia max # source /etc/profile utopia max # java-config -P sun-jdk-1.4.2.04 export JDK_HOME=/opt/sun-jdk-1.4.2.04 export JAVAC=/opt/sun-jdk-1.4.2.04/bin/javac export PATH=/opt/sun-jdk-1.4.2.04/bin:/opt/sun-jdk-1.4.2.04/jre/bin:/opt/sun-jdk-1.4.2.04/jre/javaws:${PATH} export MANPATH=${MANPATH}:/opt/sun-jdk-1.4.2.04/man export JAVA_HOME=/opt/sun-jdk-1.4.2.04 Just in case I was missing something, I then tried emerging bsf again, but still get (amongst other issues): checkJPython: [echo] Warning: JPython dependencies were not resolved.
Just to clarify, I also end up with a failed build due to missing servlet classes
Ah: but it's not that: java-config --classpath /usr/share/tomcat/lib/ant.jar:/usr/share/tomcat/lib/commons-collections.jar:/usr/share/tomcat/lib/commons-dbcp-1.1.jar:/usr/share/tomcat/lib/commons-el.jar:/usr/share/tomcat/lib/commons-pool-1.1.jar:/usr/share/tomcat/lib/jasper-compiler.jar:/usr/share/tomcat/lib/jasper-runtime.jar:/usr/share/tomcat/lib/jmx.jar:/usr/share/tomcat/lib/jmx-remote.jar:/usr/share/tomcat/lib/jmx-remote-tools.jar:/usr/share/tomcat/lib/jsp-api.jar:/usr/share/tomcat/lib/naming-common.jar:/usr/share/tomcat/lib/naming-factory.jar:/usr/share/tomcat/lib/naming-java.jar:/usr/share/tomcat/lib/naming-resources.jar:/usr/share/tomcat/lib/servlet-api.jar:/usr/share/jython/lib/jython.jar:. so it would definitely appear to be something wrong with the way the environment is set up when bsf is compiled
Re: Comment #8: Maxwell, this is what I get when I run java-config: bash-2.05b# java-config --classpath /opt/blackdown-jdk-1.4.1/jre/lib/rt.jar:. Please refer to my Comment #5. I still think you need the equivalent of /opt/blackdown-jdk-1.4.1/jre/lib/rt.jar in your classpath. Please try it as suggested in Comment #5, since that is what fixed the problem for me.
How exactly did you add it to your classpath? I have: utopia root # cat /etc/env.d/java/20sun-jdk-1.4.2.04 # Copyright 1999-2004 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-java/sun-jdk/files/sun-jdk-1.4.2.04,v 1.1 2004/03/11 01:32:12 zx Exp $ VERSION="Sun JDK 1.4.2.04" JAVA_HOME=/opt/sun-jdk-1.4.2.04 JDK_HOME=/opt/sun-jdk-1.4.2.04 JAVAC=${JAVA_HOME}/bin/javac ADDPATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin:${JAVA_HOME}/jre/javaws" ADDLDPATH="/opt/sun-jdk-1.4.2.04/jre/lib" MANPATH="/opt/sun-jdk-1.4.2.04/man" ENV_VARS="JAVA_HOME JDK_HOME JAVAC ADDPATH ADDLDPATH MANPATH" CLASSPATH=/opt/sun-jdk-1.4.2.04/jre/lib/rt.jar and utopia root # java-config -P sun-jdk-1.4.2.04 export JDK_HOME=/opt/sun-jdk-1.4.2.04 export JAVAC=/opt/sun-jdk-1.4.2.04/bin/javac export PATH=/opt/sun-jdk-1.4.2.04/bin:/opt/sun-jdk-1.4.2.04/jre/bin:/opt/sun-jdk-1.4.2.04/jre/javaws:${PATH} export CLASSPATH=/opt/sun-jdk-1.4.2.04/jre/lib/rt.jar export MANPATH=${MANPATH}:/opt/sun-jdk-1.4.2.04/man export JAVA_HOME=/opt/sun-jdk-1.4.2.04 (which presumably just prints out the env.d entries in some hashed order) but: utopia root # java-config --classpath /usr/share/tomcat/lib/ant.jar:/usr/share/tomcat/lib/commons-collections.jar:/usr/share/tomcat/lib/commons-dbcp-1.1.jar:/usr/share/tomcat/lib/commons-el.jar:/usr/share/tomcat/lib/commons-pool-1.1.jar:/usr/share/tomcat/lib/jasper-compiler.jar:/usr/share/tomcat/lib/jasper-runtime.jar:/usr/share/tomcat/lib/jmx.jar:/usr/share/tomcat/lib/jmx-remote.jar:/usr/share/tomcat/lib/jmx-remote-tools.jar:/usr/share/tomcat/lib/jsp-api.jar:/usr/share/tomcat/lib/naming-common.jar:/usr/share/tomcat/lib/naming-factory.jar:/usr/share/tomcat/lib/naming-java.jar:/usr/share/tomcat/lib/naming-resources.jar:/usr/share/tomcat/lib/servlet-api.jar:/usr/share/jython/lib/jython.jar:. still doesn't contain rt.jar Besides, if it couldn't find rt.jar, there'd be a thousand more compile time errors surely, not specifically the servlet-api ones?
(btw, I added that export CLASSPATH in the env.d entry manually, which is probably why it doesn't work ;))
Re: Comment #10 and Comment #11: Maxwell, you are almost there! (I think!) When you add CLASSPATH to the env.d entry, I believe that you must also add the word "CLASSPATH" to the line: ENV_VARS="JAVA_HOME JDK_HOME JAVAC ADDPATH ADDLDPATH MANPATH" so that it will be exported by java-config. So the line becomes: ENV_VARS="JAVA_HOME JDK_HOME JAVAC ADDPATH ADDLDPATH MANPATH CLASSPATH" Please try this. If this doesn't fix the problem, then I'm stumped. :-(
Let me give this a bash.
Ok, here's my attempted fix: The ebuild now turns off whatever CLASSPATH you have on your system. The ebuilds should work no matter what system CLASSPATH you have set. If they don't, it's a bug that needs to be fixed. Secondly, I added support for rhino and jython via useflags. Thirdly, I tested it again with tomcat-5.0.18, and it does work for me. I have not tested it with more recent tomcats, so feel free to notify me if that fails. Also, sorry for the delay. Vacation and all that...
Thanks for that - I will give it a try asap - I take it the new version is in cvs? Fwiw, I have since learnt that the significant difference between Sun and Blackdown's JDK is that to run blackdown needs the rt.jar in the CLASSPATH, which the sun jdk does not need, which would explain howard's suggested fix to me previously (and why it would'nt have made any difference ;))
Unfortunately the problem still occurs (this is on a different comp, and a fresh install...) root@nirvana max # emerge -s tomcat rhino jython Searching... [ Results for search key : tomcat ] [ Applications found : 1 ] * net-www/tomcat Latest version available: 5.0.27-r1 Latest version installed: 5.0.27 Size of downloaded files: 10,057 kB Homepage: http://jakarta.apache.org/tomcat Description: Apache Servlet-2.4/JSP-2.0 Container License: Apache-2.0 Searching... [ Results for search key : rhino ] [ Applications found : 1 ] * dev-java/rhino [ Masked ] Latest version available: 1.5-r5 Latest version installed: 1.5_rc5 Size of downloaded files: 1,486 kB Homepage: http://www.mozilla.org/rhino/ Description: Rhino is an open-source implementation of JavaScript written entirely in Java. It is typically embedded into Java applications to provide scripting to end users License: NPL-1.1 Searching... [ Results for search key : jython ] [ Applications found : 2 ] * dev-java/jython [ Masked ] Latest version available: 2.1-r4 Latest version installed: 2.1-r4 Size of downloaded files: 2,715 kB Homepage: http://www.jython.org Description: An implementation of Python written in Java License: JPython root@nirvana max # emerge /usr/portage/dev-java/bsf/bsf-2.3.0-r1.ebuild Calculating dependencies ...done! >>> emerge (1 of 1) dev-java/bsf-2.3.0-r1 to / >>> md5 src_uri ;-) bsf-src-2.3.0.tar.gz >>> Unpacking source... >>> Unpacking bsf-src-2.3.0.tar.gz to /var/tmp/portage/bsf-2.3.0-r1/work tar: A lone zero block at 5785 * Applying bsf-rhino-1.5.patch... [ ok ] >>> Source unpacked. Buildfile: build.xml init: prepare: bsf_debug-compile: [echo] Target: bsf_debug - Compile ... init: prepare: compile: [javac] Compiling 9 source files to /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/bsf_debug/build/classes [jar] Building jar: /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/bsf_debug/build/lib/bsf_debug.jar bsf-compile: [echo] Target: bsf - Compile ... init: prepare: checkDependencies: checkJacl: [echo] Warning: Jacl dependencies were not resolved. checkJPython: [echo] Warning: JPython dependencies were not resolved. checkJython: checkNetRexx: [echo] Warning: NetRexx dependencies were not resolved. checkRhino: checkXalan: compile: [javac] Compiling 23 source files to /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/bsf/build/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [jar] Building jar: /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/bsf/build/lib/bsf_core.jar jsdb-compile: [echo] Target: jsdb - Compile ... init: prepare: compile: [javac] Compiling 3 source files to /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/jsdb/build/classes [jar] Building jar: /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/jsdb/build/lib/bsf_jsdb.jar taglib-compile: [echo] Target: taglib - Compile ... prepare: compile: [javac] Compiling 2 source files to /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/build/classes [javac] /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src/taglib/src/org/apache/taglibs/bsf/expression.java:56: package javax.servlet.http does not exist [javac] import javax.servlet.http.HttpServletRequest;
one thing that's never going to help is that tomcat is now by default installed in /opt/tomcat5, rather than /opt/tomcat. However, with the ebuild changed to: local cp=/opt/tomcat5/common/lib/servlet-api.jar cp="${cp}:/opt/tomcat5/common/lib/jsp-api.jar" the build still fails, with missing servlet jar dependencies, however in: /var/tmp/portage/bsf-2.3.0-r1/work/bsf-2.3.0/src CLASSPATH=$CLASSPATH:/opt/tomcat5/common/lib/servlet-api.jar:/opt/tomcat5/common/lib/jsp-api.jar ant results in a successful compile. Might it be something to do with the way bash manages exports?
Success! I normally build with userpriv turned on (in my FEATURES environment variable from /etc/make.conf). If I remove this, the compile goes fine. Hopefully this should give you some sort of handle on how the problem might be solved...
Ah, that's a known problem. I won't handle it this time around. It will be solved with the new tomcat ebuilds. It's not a bug with bsf.
