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)
Reply-to: eric.jacob@bell.ca
From: "Eric Jacob" <eric.jacob@bell.ca>
To: users@cocoon.apache.org
Subject: RE: Deployment of Cocoon apps. Best practices?
Date: Wed, 24 Nov 2004 10:50:06 -0500
Organization: Bell Canada
Message-ID: <006d01c4d23d$451a0e30$1139758e@cmzc61>
MIME-Version: 1.0
In-Reply-To: <41A49D22.1060606@dslextreme.com>
Importance: Normal
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Sure, I'll put the process on the Wiki when tested.

Thanks,

Eric

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

Sure, no problem. Just be sure to document what you come up with on the=20
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!
>
>=20
>
>Thanks for your quick and helpful reply! :o)
>
>=20
>
> =20
>
>>What do you mean? Where else would they be but WEB-INF/lib? Are
>>
>>you meaning when they are deployed?
>>
>>   =20
>>
>=20
>
>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...
>
>=20
>
>=20
>
> =20
>
>>>Also, do you use the latest CVS version or do you use a more stable
>>>
>>>release?
>>>
>>>     =20
>>>
>>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.
>>
>>   =20
>>
>=20
>
>Sorry if this is a silly question, but what do you mean by "patch =
files"?
>
> =20
>
> If you look at the maven.xml file I attached to an earlier response=20
> you will see an xpatch task defined. This uses Cocoon's XConfToolTask=20
> to patch the root sitemap.xmap, cocoon.xconf, and any other XML files=20
> I might want to "patch". If you look at the blocks, many of them have=20
> a conf directory that has patch files in them. I believe this is=20
> documented on the wiki. Typically, I only modify the root sitemap to=20
> remove a couple of pipelines and to patch in decent pool values.
>
>=20
>
>=20
>
> =20
>
>>>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?
>>>
>>>     =20
>>>
>>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.
>>
>>   =20
>>
>=20
>
>Ok, that makes sense. Thanks for sharing this with me.
>
>=20
>
>=20
>
> =20
>
>>>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?
>>>
>>>     =20
>>>
>>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.
>>
>>   =20
>>
>=20
>
>Ok, I see.
>
>=20
>
>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?
>
> =20
>
> 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=20
> any java source, performs the patches in the config directory, copies=20
> the web.xml and the project directory (and subdirectories) and then=20
> creates a new war file. This happens for every project, if we want a=20
> separate webapp. To merge them we would need a project with multiple=20
> project subdirectories. Most everything else would be the same.
>
>
>=20
>
>=20
>
>Thanks for the advice!
>
>Dave
>
>=20
>
>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.
>
> =20
>
> Yeah. For some reason many of the emails I just do "reply" to from=20
> this list are directed to people, not the list. That should never=20
> happen, IMO. Sometimes I don't notice. As a rule I never try to=20
> respond off the list.
>
> Ralph
>


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


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