cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger I Martin PhD" <hypernex...@hypernexinc.com>
Subject Re: Cocoon 2.0 installation
Date Fri, 28 Dec 2001 15:43:15 GMT
Hi, I am employing Cocoon2 and am not a Cocoon2 developer.  I can only say what is working
and not working for me.  I have been using Apache Tomcat/4.0-b7 which stands for build 7 but
I believe any of the 4.x builds should work and tomcat is more mature than Cocoon and is usually
not causing problems in Cocoon2.  I use the cvs version and whenever I check it out I rename
the original xml-cocoon2 folder to xml-cocoon2Orig.  Then build Cocoon2 and if the build is
successful I copy it to the webapps folder which is a child of the tomcat root "jakarta-tomcat-4.0".
 Then I startup tomcat and test Cocoon as is.  Usually I check with a browser the local host
url's:

http:/localhost:8080         //usually shows the tomcat default home page.
http://localhost:8080/cocoon        //usually shows cocoon example view results but the current
cvs version is broken so I delete the new xml-cocoon2 folder and rename back the one that
was working.  It is like jumping rope; you gotta time when you jump into Cocoon versions and
after you get a successful build cling on to it as your basis whenever you try a new checkout
from the apache cvs repository.  Your in the situation that you don't have a basis yet and
there is little you can do wrong; so don't work harder than checking out new versions periodically
every day.  Don't go under the hood until you get a basis.  Send emails to this list with
the errors you log with Cocoon.  I would also suggest checking out xml-xalan and studying
xsl http://www.w3.org/Style/XSL/ till you get a basis version.  You can use xsl files with
xalan from Cocoon2 for testing some of the document transforms you want for your webapp.

I also made a shell for cleaning up the tomcat working directory:
del /S /Q "%TOMCAT_HOME%\work\localhost\cocoon"
del /S /Q "%TOMCAT_HOME%\webapps\cocoon"
del "%TOMCAT_HOME%\webapps\cocoon.war"
copy C:\apache\xml-cocoon2\build\cocoon\cocoon.war "%TOMCAT_HOME%\webapps"

Study the webapp/sitemap.xmap file to learn the lay-of-the-land but recognize that you can
put your own webapp based on cocoon in a sibling folder to the xml-cocoon2 and maintain a
Ant build script and sitemap specific to your development and change variables in the build
script to gather cocoon stuff from xml-cocoon2 to employ in your webapp.

Example:
xml-cocoon2/build.xml
<property name="src.dir" value="./src"/>

<property name="build.root" value="./build"/>

hypernex/build.xml
<property name="src.dir" value="../xml-cocoon2/src"/>

<property name="build.root" value="./build"/>

but it is important to keep your build root (destination of the whole effort) local to each
project.

This way all of the cocoon stuff can be upgraded without a large amount of maintainance by
you or mixing with your custom work.  The cocoon src is not something you will need to be
developing so that can be the same folder for all of your projects. There are many other build
variables that you can modify this way.  You can also start to alter your sitemap (change
your home page from the cocoon welcome page and site pages you want, starting with a subset
from cocoon of things your webapp specifically needs.  Don't change you sitemap or content
to locate anything outside of your webapp folder structure; keep everything you need in the
Model-View-Controller MVC structure.

Then Your webapp may be laid out like
<root>
|
+- build/
|
+- source/
|
+- webapp/
   |
   + WEB-INF/
where the build is where the ant script places all dependent and independent parts for your
webapp, both you custom stuff and cocoon base stuff and the build jars your webapp's war file.
If you change the build variables correctly, the build folder and war file should have everything
needed to deploy independent from other project folders including the cocoon project. When
tomcat expands your war file it should have everything it needs to perform; your custom stuff
and copies of cocoon base stuff; copies of all jars etc. that your webapp depends on should
be included in the war file even if this means that under tomcat/webapp there are many same
version copies of stuff; in each expanded project directory so that independence is achieved.
 If this doesn't make sense please let me know with a follow up.

Until you get over a couple of hurdles you can get frustrated with cocoon but after you get
your project environment under control your productivity will go up big time with Cocoon.
 The database pooling and handling is just one example.

Roger

  ----- Original Message ----- 
  From: reachsumit@hotmail.com 
  To: cocoon-dev@xml.apache.org 
  Sent: Thursday, December 27, 2001 11:41 AM
  Subject: Cocoon 2.0 installation


  hi everybody,
  can anyboody tell me  wht 's the best coompatible tomcat version for cocooon 2.0
  i  have  tried  the following but i am  not succes  full yet
  1]tomact  3.2.1 with  cocoon 2.0
  2]tomcat  3.2.4 with  cocoon 2.0 
  3]tomcat  3.3 with  cocoon 2.0 
  4]tomcat  4.0 with  cocoon 2.0 

  help needed .
  regards

  suumit

Mime
View raw message