cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Jacob" <eric.ja...@bell.ca>
Subject RE: Deployment of Cocoon apps. Best practices?
Date Wed, 24 Nov 2004 13:15:13 GMT
Hi Ralph,

 

Interesting. I'll try to combine the two approaches.

 

Thanks for sharing!

 

Eric

 

-----Original Message-----
From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com] 
Sent: Wednesday, November 24, 2004 12:42 AM
To: users@cocoon.apache.org
Subject: Re: Deployment of Cocoon apps. Best practices?

 

David Leangen wrote: 

Hi, Ralph!
 
Thanks for your quick and helpful reply! :o)
 
  

What do you mean? Where else would they be but WEB-INF/lib? Are
you meaning when they are deployed?
    

 
Oh, ok, I think I see what you mean. So you're essentially obtaining a
compiled webapp, so we can pretty much safely assume that all the JARs will
always be in WEB-INF/lib...
 
 
  

Also, do you use the latest CVS version or do you use a more stable
release?
      

I use the latest stable release and apply my own patches as necessary.
I actually put the cocoon src zip file in the maven repository and put
patch files there as well so that others could build what is in production
if they needed to.
    

 
Sorry if this is a silly question, but what do you mean by "patch files"?
  

If you look at the maven.xml file I attached to an earlier response you will
see an xpatch task defined.  This uses Cocoon's XConfToolTask to patch the
root sitemap.xmap, cocoon.xconf, and any other XML files I might want to
"patch".  If you look at the blocks, many of them have a conf directory that
has patch files in them. I believe this is documented on the wiki.
Typically, I only modify the root sitemap to remove a couple of pipelines
and to patch in decent pool values.



 
 
  

Eric's approach seems to depend less on the structure of how Cocoon
is built, but seems to require the developer to manually track the JARs.
Ralph's approach solves the problem of manually tracking the JARs...
but it seems that it depends on how the Cocoon project is structured.
Or am I mistaken?
      

You are correct. I initially did what Eric is doing but found that it was
a real pain to upgrade all the cocoon blocks and dependencies with
each release.  I also assume that Cocoon has been tested with the
jars it ships with so using anything else, in my mind, is not supported.
    

 
Ok, that makes sense. Thanks for sharing this with me.
 
 
  

I guess what I'm really interested in is completely automating
the build, so it works without any intervention even when Cocoon
is updated. Is this even possible, do you think?
      

Well, I build cocoon, put the war file, cocoon.jar, cocoon-testcase.jar
and cocoon-anttask (I build that from the anttask directory) in the
maven repository and then update a couple of files with the new release
umber and I am done.  I only put cocoon.jar and cocoon-testcase there
because I have custom components that require them at compile time.
They are not used when building the webapp.
    

 
Ok, I see.
 
What about your xml (or xdoc or whatever) files + stylesheets? I suppose
that you probably have various projects going on that use Cocoon... how do
you manage those projects and merge them into your Cocoon build?
  

They all use the same Cocoon war.  Each project has a file structure like:

project
-  maven.xml
-  project.xml
-  project.properties
-  config
   - various patch files for the xpatch task
-  src
    -  java
       -  java source subdirectories
    -  webapp
       -  WEB-INF
           -  web.xml (replacement for Cocoon's)
       -  directory named after project
          -  sitemap.xmap
          -  project.roles (actually, also named after the project).
          -  project subdirectories, each with their own sitemap.

Maven unwars the cocoon war file into the target directory, compiles any
java source, performs the patches in the config directory, copies the
web.xml and the project directory (and subdirectories) and then creates a
new war file.  This happens for every project, if we want a separate webapp.
To merge them we would need a project with multiple project subdirectories.
Most everything else would be the same.




 
 
Thanks for the advice!
Dave
 
BTW, is there a reason you sent this off-list? I think your advice would be
useful for others, too, if you're willing to share.
  

Yeah. For some reason many of the emails I just do "reply" to from this list
are directed to people, not the list.  That should never happen, IMO.
Sometimes I don't notice.  As a rule I never try to respond off the list.

Ralph


Mime
View raw message