Some more comments to follow Roger's email: I tried Cocoon binary download ... and it worked. Assuming that you have:
1. Servlet engine - Tomcat 4.0, Tomcat 3.3, or Resin 2.0.4 2. Windows machine or *NIX with X running (it is the case for the development machine, isn't it?) You have to just drop pre-compiled cocoon.war, and it will work out of the box as soon as container recognizes it (usually, restart is required). But: You may run into a problem if: 1. You do not have X (or never heard of it ;) 2. You do not have Xvfb (or never heard of it) 3. You never heard of PJA and you do not know how to install it. 4. You run Cocoon 2-nd, 3-rd, n-th time and see exception thrown by HSQLDB (which was not there at the first run) 5. You want to remove SVG stuff completely 6. You upgraded Cocoon and it stopped working Some of these situations are covered in the installation doc and in the FAQ, others I will try to cover here: 3: PJA installation instructions (as it was reported by some users) have flaws; it was recommended to use installation instructions provided on PJA site. 4: To run HSQLDB again, you need to delete WEB-INF/db/cocoondb.backup file (Cocoon 2.0.1 will not need this). 5: To remove SVG completely, you need to delete batik libs jar, remove all svg* serializers from the sitemap, and remove all mentions of these serializers in *all* sitemaps. After that, many users forget to shutdown server and remove old working files containing references to batik. Once these files removed, everything should work like a charm. 6: Do not forget to remove Cocoon's working directory!!! I hope I covered here 80 to 90% of the newbie problems here. Regards, Vadim > -----Original Message----- > From: Roger I Martin PhD [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 19, 2002 10:36 AM > To: [EMAIL PROTECTED] > Subject: Re: Just starting COCOON > > Understand that what you download from the apache Cocoon site is not a > software tool or IDE but a super-powered servlet with many illustrations of > how to use it, all in one huge example webapp (much beyond a typical "Hello > World!" example). Your starting point is getting this one huge example web > app to deploy once or twice on tomcat by placing the cocoon.war file in the > webapps folder of tomcat. The "as is" Cocoon installation either works or > it doesn't. There is nothing you can do right or wrong. Especially for the > Current Version System CVS revision xml-cocoon2 from the jakarta site > http://jakarta.apache.org/site/cvsindex.html. My current tomcat revision is > Apache Tomcat/4.0.2-b1. After I get a stable Cocoon revision running I use > it for a few months and back it up religiously when I go for the next cvs. > The command line: > > build.bat -Dinclude.webapp.libs=yes -Dinstall.war=%TOMCAT_HOME%\webapps > > often will not work depending on the exact TOMCAT_HOME environment variable > you are using. For example c:/Program Files/tomcat... has a space and can > cause age old problems. Just copy the cocoon.war to the > %TOMCAT_HOME%\webapps yourself. Fire tomcat up. It either works or you got > a bum revision or copy of Cocoon.war. If it doesn't work the second time you > fire it up, delete the generated ...tomcat/work/localhost/cocoon and the > ...tomcat/webapps/cocoon folders so that it has to deploy from the > cocoon.war file again. May have to do this repeatedly until you rebuild > cocoon.war without hsqldb active or start making your own webapp > project(deployed through your own *.war file). The problem is with the > hsqldb database example has a bug while shutting down. The sooner that you > rebuild cocoon from its sources with > <hsqldb-server class="org.apache.cocoon.components.hsqldb.ServerImpl" > logger="core.hsqldb-server" > pool-max="1" pool-min="1"> > <parameter name="port" value="9002"/> > <parameter name="silent" value="true"/> > <parameter name="trace" value="false"/> > </hsqldb-server> > > commented out in the src/webapp/cocoon.xconf file, the better. The the rest > of the examples will start and stop just find. Note that some of the > examples need extra jars placed in the cocoon/lib folder such as jndi.jar, > phpsrvlt.jar, etc. The important thing is to get past flopping around in > this one huge example webapp and start your own serious webapp as soon as > possible after you see Cocoon's one huge example webapp run once or twice. > > Cocoon is not a typically installed software package and so to apply it to > your own web app at first is not intuitive. The documentation has a long > way to go to catch up; remember it is a work in progress and tends to assume > that we know the small but totally baffling how-to-get-started stuff. I > finally discovered a cool way to do it and perhaps with editing from the > Cocoon 2 Team we can put together a "How to apply Cocoon 2" for their web > site. The most important thing is to set up your own webapp project build > area. This takes some work but you can do it in stages. To start, create a > project folder(sibling to the xml-cocoon2 folder), name it according to your > project, prepare your directory structure: > > +->lib > <all of the jars from your current working xml-cocoon2/lib folder> > <plus the cocoon.jar from the xml-cocoon2/build/cocoon folder> > //this is key because now your own build can be simplyfied > +->src //For your own custom additions to cocoon > +->documentation //At first just a copy from the xml-cocoon2/src > //You can eventually put your own or only things you need here > +->java //Only your own custom code here. No cocoon code because > cocoon.jar already has the compiled Cocoon classes. > +->webapp //At first a copy of the webapp from xml-cocoon2/src > //This you start modifying starting with the homepage > //and sitemap.xmap > appendcp.bat > //classpath appender > build.bat > build.xml //A stripped down or commented out revision from the one > //in the xml-cocoon2 folder. Have it generate a build > folder > // for construction of your webapp jar and war files. > database.properties. > //set up your database initialization > //you will need to set somethings according to > // > http://xml.apache.org/cocoon/developing/datasources.html > > Your custom webapp's build.xml can be pared down considerably from the huge > example cocoon webapp. Until you make custom source code additions to your > ...src/java folder you can disable the compile target. Mostly you are > having it build the stuff it needs for your war file while applying build > variables such as > database-driver=org.gjt.mm.mysql.Driver. > > > The next stage is studying the ...src/webapp/sitemap.xmap file and modify > the welcome pattern matching to something you know and want. There is no > need to pare the sitemap.xmap file down; eventually you will need more and > more of it and anything not in immediate use just lies dormant. Finding the > first welcome page can require some sleuthing. Currently it is nearly half > way down sitemap.xmap and looks like: > <map:pipeline> > > <map:match pattern=""> > > <map:redirect-to uri="welcome"/> > > </map:match> > > <map:match pattern="welcome"> > > <map:generate src="docs/samples/samples.xml"/> > > ... > > So ...src/webapp/docs/samples/samples.xml is the home page! For those > familiar with Cocoon, this is no surprise but this was where I first started > to catch on! What it meant to me is that I could start building my own > serious webapp now that I had the starting page and could study, modify > small parts of the whole to observe the changes that would occur after each > redeployment on tomcat. I changed the welcome pattern matching to: > <map:pipeline> > <map:match pattern=""> > > <map:redirect-to uri="welcome"/> > > </map:match> > > <map:match pattern="welcome"> > > <map:generate src="home.xml"/> > > where home.xml is a stripped down ...src/webapp/docs/samples/samples.xml to > pieces pertinent to my serious webapp. It depends at this point on what you > want your web app to do. For me I already had a number of mysql databases I > wanted to display and administrate so I studied > http://xml.apache.org/cocoon/developing/datasources.html and pooled them up. > Then got into my own xsp development applying the esql.xsl stylesheet. > Studying xsl is very important for creating your own webapp's consistent > look and feel. The consistent look and feel is maintained by the xsl > stylesheets and the formatted objects namespace > xmlns:fo="http:www.w3.org/1999/XSL/Format". Only a few of the xsl > stylesheets in the one huge example cocoon webapp are sacred and those are > mostly in ...src/java. Others such as > ...src/webapp/stylesheets/page/simple-page2html.xsl you are encouraged to > modify, rename or replace (updating the sitemap.xmap pattern matching > required) in your webapp. The power of Cocoon is that when you change a > presentation attribute or style, after the next build and deployment, your > entire website has the new look and feel consistently throughout it's pages. > After some up front hard work, web site maintainance becomes dynamic and > fun; not a mundane chore. Here we would need to branch into chapters; one > for each stylesheet or webapp segments goal? > > This is Saturday morning, January 19 and I just couldn't focus on my > projects so I tried to help someone else instead. Those just starting keep > asking [specific] questions and those with more experience than me, please > revise this description of "How to apply Cocoon 2" or use anything from this > message if you find anything includable in the documentation. > > Regards, > > Roger > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, January 18, 2002 2:56 PM > Subject: RE: Just starting COCOON > > > > I have got to work but have a difficult time understanding. I tried some > > samples with devshed and could not get them to work. > > > > Sree > > x5178 > > --------------------------------------------------------------------- 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]>
