Sure, I'll put the process on the Wiki when tested. Thanks,
Eric -----Original Message----- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 9:40 AM To: [EMAIL PROTECTED] Subject: Re: Deployment of Cocoon apps. Best practices? 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:[EMAIL PROTECTED] > *Sent:* Wednesday, November 24, 2004 12:42 AM > *To:* [EMAIL PROTECTED] > *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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
