On Tue, 15 Oct 2002, Ken Gunderson wrote: Since there seems to be some confusion concerning classpaths, I will try to clarify things here. Maybe this helps some people:
1. setting your CLASSPATH=/your/class/path and then putting eg. jaxp.jar at /your/class/path/jaxp.jar will NOT do anything for you. The classes in jaxp.jar won't be added to your classpath. 2. one way to add a jar-file to your classpath is to specify it explicitly (eg. CLASSPATH=/whereever/you/keep/jars/jaxp.jar) 3. another way is to put it into the jdk at $JDK_HOME/jre/lib/ext/ 4. neither 2. nor 3. is recommended for the jars needed by webapps (and there are some good reasons for this, just believe me). 5. tomcat has its own classloader that adds jars from the directories /tomcat/lib, /tomcat/common/lib, /tomcat/webapps/some-webapp/WEB-INF/lib to the classpath. There are some libraries (eg. velocity) that have been split in two, because one part needs to be put in /tomcat/lib or /tomcat/common/lib (eg. velocity-dep.jar) and the other must be in your webapp's library dir (velocity.jar). (so RTFM before putting jars somewhere!) 6. tomcat classloader also loads classes from /tomcat/webapps/some-webapp/WEB-INF/classes As with 1. that does not mean it loads .jar-files from there, only .class-files, that are placed into the correct subdirs (depending on their package) 7. ant knows nothing about the way tomcat loads classes at runtime. That's why the build.xml and build.properties file tell ant where to find it's stuff (ie. its classpath). 8. ant itself is a java app and needs some libraries to run. That's why you should set the ANT_HOME environment variable (build.sh/build.bat may do this for you) and ant (or rather the script in $ANT_HOME/bin) will be smart enough to load those from $ANT_HOME/lib. 9. 7 and 8 apply to ant 1.4.1. I have not tried ant 1.5 yet, but I guess it won't be to different. I hope I got all those paths right. I also hope I did not further confuse anyone. > since top posting seems to be the preference here... > > please note that my efforts to build source tree ensued only after > failure with the precompiled jetspeed.war (1.4b1, i believe) hope i > didn't infer that jetspeed itself was slacking. i think this is more > of a java, rather than jetspeed, thing. my experience thus far has > been little to no help from more than one source approached in an > effort to track this down. seems like there are all these parts and > nobody really knows how they are supposed to play together, just that > they do in a perfect world. when the world is less than perfect the > default seems to be pointing the finger elsewhere and saying it's not > my issue... > > shooting from the hip a bit here, as i've not been into java long enough > to be forming firm imperssions, but am rather reporting my initial > perceptions thus far. ymmv... and i'm not trolling for a my language > is better than yours flame war. i'd just like to figure the damn thing > out. > > that i'm having a classpath issue has definitley occured to me, but my > classpath is set in my shell environment, and is apparenly inherited > during the build. so how do i track the problem further?? the fbsd > crimson port used to install jaxp.jar in /usr/local/share/java/classes, > but does so no longer, as install advises thusly: > > The following jar file has been installed: > > /usr/local/share/java/classes/crimson.jar > > Add it to your CLASSPATH to use JAXP. > > NOTE: > If you used previous versions of crimson, please note that there is > now only one jar file, crimson.jar. You should remove the old port > and any references to the jaxp.jar to avoid confusion. > > thus ant apparently becomes broken since it relies on crimson as > dependncy... > > so am i supposed to remove all reference to jaxp.jar in the source?? > (i'm being facetious here....) > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
