Thank you, Ralph, for your input on this thread. Once I've got a deployment routine I'm comfortable with, I'll put together a document describing what I have done, and how I feel about it. I might start a new thread on this list before I do so to discuss my process with you other guys.
Best regards, Bent On Wed, 24 Nov 2004 06:39:30 -0800, Ralph Goers <[EMAIL PROTECTED]> wrote: > 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]
