Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41A49D22.1060606@dslextreme.com>
Date: Wed, 24 Nov 2004 06:39:30 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Deployment of Cocoon apps. Best practices?
References: <001e01c4d227$a1f063e0$1139758e@cmzc61>
In-Reply-To: <001e01c4d227$a1f063e0$1139758e@cmzc61>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Sure, no problem. Just be sure to document what you come up with on the 
Wiki!

Raph

Eric Jacob wrote:

> 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
>


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