Re: Employing, maintaining, version upgrades

2001-12-26 Thread reachsumit 

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 <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > 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
> > >
> > > 
> > > |
> > > +- 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 -> [EMAIL PROTECTED]
> > >
> > > -
> > > 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: <[EMAIL PROTECTED]>
> > > For additional commands, e-mail: <[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> >
> > -
> > 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: <[EMAIL PROTECTED]>
> > For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
> -
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>

-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Employing, maintaining, version upgrades

2001-12-26 Thread Peter Royal 

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 -> [EMAIL PROTECTED]

-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Employing, maintaining, version upgrades

2001-12-26 Thread Robert Koberg 

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
> >
> > 
> > |
> > +- 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 -> [EMAIL PROTECTED]
> >
> > -
> > 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: <[EMAIL PROTECTED]>
> > For additional commands, e-mail: <[EMAIL PROTECTED]>
> >
> >
>
>
>
> -
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>


-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Employing, maintaining, version upgrades

2001-12-26 Thread Roger I Martin PhD 

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
> 
> |
> +- 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 -> [EMAIL PROTECTED]
>
> -
> 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: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>



-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Employing, maintaining, version upgrades

2001-12-26 Thread Peter Royal 

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


|
+- 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 -> [EMAIL PROTECTED]

-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>