Organizing own project in cocoon?

[Fe...@thomson.com]

I read that what's recommended is to create a block for one's project.

But as I see it, one needs no modify ant files, web.xml etc., so
upgrading

to a new version of cocoon becomes a mess.

Is there any clean way of using cocoon?

 

Re: Organizing own project in cocoon?

[Simone Gianni <s....@thebug.it>]

Hi Fernando,
IMMO organizing your project as a block is a good way of doing it if you 
need extreme control on the cocoon environment, but for the 90% of 
cocoon projects it's not needed.

You can simply create your directly structure composed by a folder (we 
usually have src/webapp) containing a sitemap.xmap and all the other 
stuff you need. Usually we have a src/webapp/resource folder, containing 
other folders like img, javascript etc.. for all the client side stuff. 
Then we usually create a stylesheets folder containing common xsls. 
Other application folders depend on the size and destination of your 
application, for example for an ecommerce site i would create folders 
like cart, catalogue, payment etc... all containing the needed files 
(forms, etc..) eventually creating other subfolders if needed.

Then we usually have a src/main/ source folder containing java sources 
(and eventually a src/test folder containing junit tests). We also quite 
commonly use a lib/runtime and lib/compile folders, in lib/runtime we 
place jars needed by our application and not already included in cocoon, 
while in lib/compile we copy from cocoon the cocoon jars needed to have 
eclipse compile our java sources (if we develop custom cocoon components 
in that application).

The build process if quite simple (can do with 20/30 lines of code), 
common operations are :
- Compile you java classes, pack them in a jar, and place them in the 
target {$cocoon-webapp}/WEB-INF/lib
- Copy lib/runtime/*.jar to {$cocoon-webapp}/WEB-INF/lib.
- Copy your src/webapp into {$cocoon-webapp}/yoursitename
- Eventually patch (XPatch) various cocoon configuration files to 
install your custom classes, if you need this

Common xpatches are :
- Patches to web.xml to install custom filters, servlets, or to change 
default cocoon parameters (quite common is the upload on disk and max 
upload size)
- Patches to cocoon.xconf to configure and install your own cocoon forms 
(or other block's) components.
- Patches to the root sitemap.xmap to add global matches (quite common, 
redirecting "" to "/yoursitename/")

While developing, is quite handy to use the mount-table.xml instead of 
copying your src/webapp folder to cocoon. This file defines that 
/yourappname points to, say, 
"c:\Programs\Eclipse\workspace\siteproject\src\webapp\". This way you 
can change your application files (forms, xsl etc..) directly inside 
your ide, and see them change immediately, using the build only when you 
change java sources, and thus speeding the developement process a lot.

In some projects, we also add an optional target in the ant build that 
would download the required cocoon version, unpack it, copy in the 
cocoon folder the local.build.properties and local.blocks.properties 
with trimmed versions made up for your application, and then launch the 
cocoon build. I don't like this very much, but can save your customer a 
lot of time in redeploy/manteinance and avoid to have them call you back 
after one month asking which version of cocoon they need or why they are 
having those ClassNotFoundExceptions (missing a block).

Organizing a block would automagically solve a lot of this problems 
(since all the build is done by the cocoon build, including xpatches, 
copying of webapp files, carrying needed jars etc.., you just have to 
organize files in a certain way and copy them in the cocoon folder), but 
IMMO is a bit overkill for simple cocoon based applications.

Simone

-- 
Simone Gianni

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Organizing own project in cocoon?

[Bruno Dumon <br...@outerthought.org>]

On Thu, 2006-03-02 at 12:21 +0100, Fernando.Matomira@thomson.com wrote:
> I read that what’s recommended is to create a block for one’s project.
> 
> But as I see it, one needs no modify ant files, web.xml etc., so
> upgrading
> 
> to a new version of cocoon becomes a mess.
> 
> Is there any clean way of using cocoon?
> 

I wouldn't use it as a block, since as you indicated this requires
modifying the original Cocoon source tree.

I'm a bit suprised I didn't see a reference yet to this:

http://cocoon.zones.apache.org/daisy/cocooninaction/14.html

which is a solution that allows to easily build cocoon (with your own
build options), adjust configuration with xpatch, builds your java code,
copies resources, etc. This is an updated version of the
"YourCocoonBasedProject" thing on the Cocoon Wiki.

This is pretty similar to what Simone suggested, but the Ant script you
can download there is immediately useable, in a couple of minutes you're
up and running.

This solution also allows to easily 'switch' cocoon versions, e.g. to
try it out with a new cocoon version.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org