I've noted how often this question comes up. I'm probably just asking for trouble by writing this follow-up HOWTO (someone will highlight something that I forgot to mention), but I thought it might keep poor Vadim's responses to a minimum (assuming my information is accurate).
My installation environment consists of a Redhat 7.2 Linux server, with all the latest "upgrade" packages installed. I'm running a "headless" server, implying that I don't require the XServer or the Xvfb to render SVGs, PDFs, and anything else that employs the batik classes used in Cocoon 2. Here are the various Apache and Sun RPMs and packages I've installed: Tomcat 4.0.3 RPM (I decided it was too much work to build the sources myself). Cocoon 2.0.2 distribution (this I compiled myself). Ant 1.4.1 (I compiled the distribution myself) Batik 1.5 beta distribution (I compiled this myself) Sun J2SDK 1.4.0 RPM I like using the tomcat RPMs because they provide all the necessary startup scripts. With very little modification you can usually start Tomcat up. You also don't have to go and collect all those jar files needed for Tomcat yourself. The only major things I had to do were: 1. To add the bin directory of the J2SDK to my PATH variable. 2. Set the JAVA_HOME environmental variable to the correct location for my system. This meant editing the tomcat4.conf file that is part of the RPM distribution since it defaults to the IBM JDK 1.3 JVM. 3. Edited the /usr/sbin/dtomcat4 script, specifying the option "-Djava.awt.headless=true" when tomcat4 starts up, so that I can avoid using the XServer or Xvfb. When compiling the batik 1.5 package, I ran ant and specified the "all-jar" option so that it would build the batik-all.jar file. When compiling cocoon 2.0, I built the cocoon.war file, installed it in an appropriate location under my tomcat webapps subdirectory, and unjarred it. I then removed the xalan, xerces and xml-apis jar files, as well as the xt and batik files. Presumably because JDK 1.4 includes versions of xerces, xalan and the jaxp stuff, you don't need any of these to get cocoon to run with this version. I've seen references to removing xt in previous notes, besides, I see it as just an "extra" jar (no offense to James Clark) that can be eliminated. I'm aware that there are newer versions of xerces, xalan, etc. than those included in the jdk 1.4. I believe that the new standard mechanism for substituting alternate jaxp implementations is to specify an "endorsed" class path when you are running a java application (correct me if I'm wrong about this, I haven't tried it). Presumably you could override the default classes following this approach if you wanted to do this. In the WEB-INF subdirectory where my unjarred cocoon.war appears, I edited the web.xml file. I added the following like under the extra-classpath parameter: <your-path-to>/batik.jar . I made sure that I copied my batik-all.jar to that same location. I made a few minor changes to the server.xml file in the conf subdirectory of my tomcat installation with regards to host names, and the context and paths where to find the cocoon installation. These will obviously vary with the user. Then I started up tomcat and lo and behold, it actually ran just fine. I didn't test every single example since my particular uses for Cocoon are rather mundane (document delivery, basically) but I think most of them are working just fine. I hope I haven't left anything "vital" out. You should be able to compile your own apache packages using Ant, I found that I just had to be careful to set and export my JAVA_HOME and ANT_HOME environment variables to get everything work. About the only thing I always seem to have problems with is generating the javadocs for these packages... I get a lot of error messages, but since the docs are usually available on-line, I don't worry about it too much. Good luck... Rob --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
