You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Roger I Martin PhD <hy...@hypernexinc.com> on 2001/12/26 15:33:19 UTC
Employing, maintaining, version upgrades
Hi,
For applicators of Cocoon2; what is the recommended method for creating
multiple projects based on Cocoon? I currently create sibling project
folders to xml-cocoon2 and customize the projects build.xml to locate Cocoon
components and maintain a unique webapp folder for each project. There are
times when the projects become broken when I cvs update the xml-cocoon2
folder and then I need to search for obsolescence in my projects which can
be a daunting task at times. What project layout is best? Where should I
break between Cocoon2 and Cocoon2 based projects?
Roger
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Employing, maintaining, version upgrades
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 26 December 2001 01:00 pm, you wrote:
> Wouldn't it be better to keep you xslt, xml (and all things that you don't
> want or need the user to access) underneath WEB-INF? This way you keep
> things more secure. Keep things like css or js (things that need to be
> downloaded) in the docroot.
Good point :) I'll try to remember that next time I'm moving a bunch of files
around in my project.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Employing, maintaining, version upgrades
Posted by re...@hotmail.com.
hi ,
i have downloaded the cocoon 2 zip file can somebody tell me how to
cofiigure it.
Unlike cocoon 1.8 it does not create all the directory from where it can
cut and pasted in to tomcat 3.2.4 directory's.
I have gone through the installation help files but i am still unable too
understand the entire procedure
regards
sumit
----- Original Message -----
From: Robert Koberg <ro...@koberg.com>
To: <co...@xml.apache.org>
Sent: Wednesday, December 26, 2001 11:30 PM
Subject: Re: Employing, maintaining, version upgrades
> hi,
>
> Wouldn't it be better to keep you xslt, xml (and all things that you don't
> want or need the user to access) underneath WEB-INF? This way you keep
> things more secure. Keep things like css or js (things that need to be
> downloaded) in the docroot.
>
> best,
> -Rob
>
>
>
> ----- Original Message -----
> From: "Roger I Martin PhD" <hy...@hypernexinc.com>
> To: <co...@xml.apache.org>
> Sent: Wednesday, December 26, 2001 7:55 AM
> Subject: Re: Employing, maintaining, version upgrades
>
>
> > Thanks, that was quick!
> >
> > I'll apply your project source tree and be able to continue working this
> > week. The logkit.xconf was where I was missing some changes.
> >
> > Happy New Year,
> >
> > Roger
> > ----- Original Message -----
> > From: "Peter Royal" <pr...@managingpartners.com>
> > To: <co...@xml.apache.org>
> > Sent: Wednesday, December 26, 2001 9:48 AM
> > Subject: Re: Employing, maintaining, version upgrades
> >
> >
> > > On Wednesday 26 December 2001 09:33 am, you wrote:
> > > > For applicators of Cocoon2; what is the recommended method for
> creating
> > > > multiple projects based on Cocoon? I currently create sibling
project
> > > > folders to xml-cocoon2 and customize the projects build.xml to
locate
> > > > Cocoon components and maintain a unique webapp folder for each
> project.
> > > > There are times when the projects become broken when I cvs update
the
> > > > xml-cocoon2 folder and then I need to search for obsolescence in my
> > > > projects which can be a daunting task at times. What project layout
> is
> > > > best? Where should I break between Cocoon2 and Cocoon2 based
> projects?
> > >
> > > We have a Cocoon2-based project here. In my project source tree I have
> > >
> > > <root>
> > > |
> > > +- build/
> > > |
> > > +- source/
> > > |
> > > +- web/
> > > |
> > > + WEB-INF/
> > > |
> > > + lib/
> > >
> > > And more, but that's the guts really. web is our version of the
cocoon2
> > > webapp folder, source is our personal source tree, and build is where
we
> > > build the code.
> > >
> > > I don't sync with Cocoon proper on a regular basis, but when I do I:
> > >
> > > 1) Get latest of the Cocoon source
> > > 2) compile as: build -Dinclude.webapp.libs=yes webapp javadocs
> > > 3) copy the contents of the generated webapp/WEB-INF/lib into my
> > > corresponding folder
> > > 4) manually update my cocoon.xconf and logkit.xconf to match whatever
> new
> > > constructs/log targets have been added.
> > >
> > > Thus the cocoon.jar that I am using is always local to my project in
its
> > > web/WEB-INF/lib directory (and same with all of the other jars that
> Cocoon
> > > depends upon). It has worked out well for us.
> > > -pete
> > >
> > >
> > > --
> > > peter royal -> proyal@managingpartners.com
> > >
> > > ---------------------------------------------------------------------
> > > Please check that your question has not already been answered in the
> > > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> > >
> > > To unsubscribe, e-mail: <co...@xml.apache.org>
> > > For additional commands, e-mail: <co...@xml.apache.org>
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Employing, maintaining, version upgrades
Posted by Robert Koberg <ro...@koberg.com>.
hi,
Wouldn't it be better to keep you xslt, xml (and all things that you don't
want or need the user to access) underneath WEB-INF? This way you keep
things more secure. Keep things like css or js (things that need to be
downloaded) in the docroot.
best,
-Rob
----- Original Message -----
From: "Roger I Martin PhD" <hy...@hypernexinc.com>
To: <co...@xml.apache.org>
Sent: Wednesday, December 26, 2001 7:55 AM
Subject: Re: Employing, maintaining, version upgrades
> Thanks, that was quick!
>
> I'll apply your project source tree and be able to continue working this
> week. The logkit.xconf was where I was missing some changes.
>
> Happy New Year,
>
> Roger
> ----- Original Message -----
> From: "Peter Royal" <pr...@managingpartners.com>
> To: <co...@xml.apache.org>
> Sent: Wednesday, December 26, 2001 9:48 AM
> Subject: Re: Employing, maintaining, version upgrades
>
>
> > On Wednesday 26 December 2001 09:33 am, you wrote:
> > > For applicators of Cocoon2; what is the recommended method for
creating
> > > multiple projects based on Cocoon? I currently create sibling project
> > > folders to xml-cocoon2 and customize the projects build.xml to locate
> > > Cocoon components and maintain a unique webapp folder for each
project.
> > > There are times when the projects become broken when I cvs update the
> > > xml-cocoon2 folder and then I need to search for obsolescence in my
> > > projects which can be a daunting task at times. What project layout
is
> > > best? Where should I break between Cocoon2 and Cocoon2 based
projects?
> >
> > We have a Cocoon2-based project here. In my project source tree I have
> >
> > <root>
> > |
> > +- build/
> > |
> > +- source/
> > |
> > +- web/
> > |
> > + WEB-INF/
> > |
> > + lib/
> >
> > And more, but that's the guts really. web is our version of the cocoon2
> > webapp folder, source is our personal source tree, and build is where we
> > build the code.
> >
> > I don't sync with Cocoon proper on a regular basis, but when I do I:
> >
> > 1) Get latest of the Cocoon source
> > 2) compile as: build -Dinclude.webapp.libs=yes webapp javadocs
> > 3) copy the contents of the generated webapp/WEB-INF/lib into my
> > corresponding folder
> > 4) manually update my cocoon.xconf and logkit.xconf to match whatever
new
> > constructs/log targets have been added.
> >
> > Thus the cocoon.jar that I am using is always local to my project in its
> > web/WEB-INF/lib directory (and same with all of the other jars that
Cocoon
> > depends upon). It has worked out well for us.
> > -pete
> >
> >
> > --
> > peter royal -> proyal@managingpartners.com
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Employing, maintaining, version upgrades
Posted by Roger I Martin PhD <hy...@hypernexinc.com>.
Thanks, that was quick!
I'll apply your project source tree and be able to continue working this
week. The logkit.xconf was where I was missing some changes.
Happy New Year,
Roger
----- Original Message -----
From: "Peter Royal" <pr...@managingpartners.com>
To: <co...@xml.apache.org>
Sent: Wednesday, December 26, 2001 9:48 AM
Subject: Re: Employing, maintaining, version upgrades
> On Wednesday 26 December 2001 09:33 am, you wrote:
> > For applicators of Cocoon2; what is the recommended method for creating
> > multiple projects based on Cocoon? I currently create sibling project
> > folders to xml-cocoon2 and customize the projects build.xml to locate
> > Cocoon components and maintain a unique webapp folder for each project.
> > There are times when the projects become broken when I cvs update the
> > xml-cocoon2 folder and then I need to search for obsolescence in my
> > projects which can be a daunting task at times. What project layout is
> > best? Where should I break between Cocoon2 and Cocoon2 based projects?
>
> We have a Cocoon2-based project here. In my project source tree I have
>
> <root>
> |
> +- build/
> |
> +- source/
> |
> +- web/
> |
> + WEB-INF/
> |
> + lib/
>
> And more, but that's the guts really. web is our version of the cocoon2
> webapp folder, source is our personal source tree, and build is where we
> build the code.
>
> I don't sync with Cocoon proper on a regular basis, but when I do I:
>
> 1) Get latest of the Cocoon source
> 2) compile as: build -Dinclude.webapp.libs=yes webapp javadocs
> 3) copy the contents of the generated webapp/WEB-INF/lib into my
> corresponding folder
> 4) manually update my cocoon.xconf and logkit.xconf to match whatever new
> constructs/log targets have been added.
>
> Thus the cocoon.jar that I am using is always local to my project in its
> web/WEB-INF/lib directory (and same with all of the other jars that Cocoon
> depends upon). It has worked out well for us.
> -pete
>
>
> --
> peter royal -> proyal@managingpartners.com
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Employing, maintaining, version upgrades
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 26 December 2001 09:33 am, you wrote:
> For applicators of Cocoon2; what is the recommended method for creating
> multiple projects based on Cocoon? I currently create sibling project
> folders to xml-cocoon2 and customize the projects build.xml to locate
> Cocoon components and maintain a unique webapp folder for each project.
> There are times when the projects become broken when I cvs update the
> xml-cocoon2 folder and then I need to search for obsolescence in my
> projects which can be a daunting task at times. What project layout is
> best? Where should I break between Cocoon2 and Cocoon2 based projects?
We have a Cocoon2-based project here. In my project source tree I have
<root>
|
+- build/
|
+- source/
|
+- web/
|
+ WEB-INF/
|
+ lib/
And more, but that's the guts really. web is our version of the cocoon2
webapp folder, source is our personal source tree, and build is where we
build the code.
I don't sync with Cocoon proper on a regular basis, but when I do I:
1) Get latest of the Cocoon source
2) compile as: build -Dinclude.webapp.libs=yes webapp javadocs
3) copy the contents of the generated webapp/WEB-INF/lib into my
corresponding folder
4) manually update my cocoon.xconf and logkit.xconf to match whatever new
constructs/log targets have been added.
Thus the cocoon.jar that I am using is always local to my project in its
web/WEB-INF/lib directory (and same with all of the other jars that Cocoon
depends upon). It has worked out well for us.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>