You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Timothy Larson <ti...@yahoo.com> on 2003/08/28 16:05:46 UTC
[Proposal] Simple "production build" directions
--Simple proposal for a "production build" for Cocoon--
Create a new file "production.build.properties,
and refer to it in a new step 2 in INSTALL.txt:
Proposed changes to "INSTALL.txt":
(Insert a new step 2)
2) For a full build skip to step 3
To make a production build without the documentation, samples, scratchpad,
or deprecated code simply copy the file "production.build.properties"
to "local.build.properties" before going on to step 3.
See below if you are rebuilding or wish to further customize the build.
(And, of course, renumber the following steps)
3) Build Cocoon by typing "build" or "./build.sh"
4) Run Cocoon by typing "cocoon servlet" or "./cocoon.sh servlet"
5) Open http://localhost:8888/ with your browser
Proposed new file "production.build.properties":
# ---- Webapp Exclusions ----
exclude.webapp.documentation=true
exclude.webapp.javadocs=true
exclude.webapp.idldocs=true
exclude.webapp.scratchpad=true
exclude.webapp.samples=true
# ---- Build Exclusions ----
exclude.scratchpad=true
exclude.deprecated=true
exclude.javadocs=true
exclude.idldocs=true
How is this for a simple solution?
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [Proposal] Simple "production build" directions
Posted by Timothy Larson <ti...@yahoo.com>.
Lets try to fix the first issue on your list.
The last target in src/targets/webapp-build.xml is "custom-conf".
This is the only place the "customconf" property is used.
Notice that the "customconf" property is applied to the included
filename, not to the "srcdir" attribute:
<xpatch file="${build.webapp}/WEB-INF/cocoon.xconf" srcdir="" addComments="true">
<include name="${customconf}/*.xconf" />
</xpatch>
If I read the xpatch source code correctly, this limits the customconf to
only working with subdirectories. I think we can fix this by changing the
target to apply the customconf to the srcdir instead of to the included
filename, like this:
<xpatch file="${build.webapp}/WEB-INF/cocoon.xconf" srcdir="${customconf}" addComments="true">
<include name="*.xconf" />
</xpatch>
Here is the whole converted target if you would not mind testing it
with your desired configuration:
<target name="custom-conf" depends="init-tasks" description="Uses Cocoon's xpatch task to
customize runtime configuration">
<xpatch file="${build.webapp}/sitemap.xmap" srcdir="${customconf}">
<include name="*.xmap" />
<include name="*.xpipe" />
</xpatch>
<xpatch file="${build.webapp}/WEB-INF/cocoon.xconf" srcdir="${customconf}" addComments="true">
<include name="*.xconf" />
</xpatch>
<xpatch file="${build.webapp}/WEB-INF/logkit.xconf" srcdir="${customconf}">
<include name="*.xlog" />
</xpatch>
<xpatch file="${build.webapp}/WEB-INF/web.xml" srcdir="${customconf}">
<include name="*.xweb" />
</xpatch>
</target>
Please let me know how this goes,
--Tim Larson
--- Tomasz Nowak <tn...@netventure.pl> wrote:
...
> 1. customconf property doesn't work properly at my linuxbox :(
> I have some .xweb, .xconf and .xmap files in 'myconf'
> directory but they are not seen by buildtools when
> 'myconf' is outside cocoon source directory.
>
> customconf=../myconf <- doesn't work.
> after moving it into cocoonsrc dir ($ mv ../myconf .)
> and changing customconf in local.build.properties to:
> customconf=myconf
> everything works fine.
>
> Of course file permis and modes are ok. Is this a bug?
...
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [Proposal] Simple "production build" directions
Posted by Tomasz Nowak <tn...@netventure.pl>.
Timothy Larson <ti...@yahoo.com> wrote:
>
> Thanks for the suggestion. I added the proposal to the wiki here:
> http://wiki.cocoondev.org/Wiki.jsp?page=ProductionInstallProposal
I won't edit that file but I would like to add here my suggestion
about cocoon-2.1 build system, in general. I try to contribute to
Cocoon project as much as I can and I hope my 2 cents will help
you improve that great product Coocoon is.
According to my expirence some issues make building uncomfortable.
These issues are:
1. customconf property doesn't work properly at my linuxbox :(
I have some .xweb, .xconf and .xmap files in 'myconf'
directory but they are not seen by buildtools when
'myconf' is outside cocoon source directory.
customconf=../myconf <- doesn't work.
after moving it into cocoonsrc dir ($ mv ../myconf .)
and changing customconf in local.build.properties to:
customconf=myconf
everything works fine.
Of course file permis and modes are ok. Is this a bug?
2. The second issue that is annoying for me is that
the distribution build.sh is so little parametrized.
There should be a possibility for invoking build.sh with
local.build.properties and local.blocks.properties as
parameters ($2, $3), for example:
.build.sh webapp ../myconf/mywebapp.build.properties \
../myconf/mywebapp.blocks.properties
I think this is a must.
3. Next issue is prepare-webapp target.
Lets say I have some 'initial' dirs and files in ../mywebapp:
../mywebapp/content/
../mywebapp/content/welcome.xml
../mywebapp/logic/
../mywebapp/style/
../mywebapp/style/images/
../mywebapp/style/javascripts/
../mywebapp/style/javascripts/system/
../mywebapp/style/javascripts/system/error.js
../mywebapp/style/stylesheets/
../mywebapp/style/stylesheets/welcome.xsl
../mywebapp/style/stylesheets/system/
../mywebapp/style/stylesheets/system/error.xsl
../mywebapp/WEB-INF/
../mywebapp/WEB-INF/.. <-- here the same files as in
src/webapp/WEB-INF
but this is not the way
I'd like
Of course I do default pipelines substitute
by xpatch at ../myconf/pipelines.xmap:
<xmap xpath="/sitemap"
remove="/sitemap/pipelines"
if-prop="config.pipelines">
<map:pipelines>
<!-- ... mypipelines here ... -->
</map:pipelines>
<xmap>
webapp property of local.build.properties seemed
promising at first, but then I realized that
webapp-build.xml copies only specific files
and directories that are in distribution (file
per file). So I can't change the layout of my
brand new built webapp :(
I think prepare-webapp target should copy
to build.webapp dir:
1) only WEB-INF/ from src/webapp
2) probably also samples from src/webapp
(if exclude.webapp.samples not true)
3) and then copy whole directory set by
'webapp' property (../mywebapp)
- overwriting .xfiles if any i mywebapp,
- combining ../mywebapp/WEB-INF/classes
with build/webapp/WEB-INF/classes
- combining ../mywebapp/samples with
samples etc..
This just my idea.
4. I really don't understand why
src/blocks/databases/conf/datasources.xconf
is in databases block, not in hsqldb block.
If that node is to be an example for database
usage - it should be a) commented out and probably
b) configured to example a more common database
(propably these one's that that drivers are included
by local.build.properties)
<datasources>
<!--
<jdbc name="postgres">
<pool-controller min="5" max="10"/>
<auto-commit>true</auto-commit>
<dburl>jdbc:postgresql://localhost:5432/test?charSet=UTF-8</dburl>
<user></user>
<password></password>
</jdbc>
-->
</datasources>
5. src/blocks/databases/conf lacks still popular mysql.Driver.xweb.
I know PostgreSQL is much better, but...
-------------------------------------------------------------------
Going back to production build setup - I generally agree with
ProductionInstallProposal that are at wiki right now, but
I have some additional remarks:
a) WHEN any of include.driver.* is set to true, corresponding
commented out datasource included by databases/conf/datasources.xconf
SHOULD BE uncommented then
b) shouldn't be config.enable-uploads set to true?
-------------------------------------------------------------------
If 1, 2, 3, 4, 5 and a) where implemented - the build system
would be just ideal for me :)
--
Tomasz Nowak
Netventure, http://www.netventure.pl/
Re: [Proposal] Simple "production build" directions
Posted by Timothy Larson <ti...@yahoo.com>.
Thanks for the suggestion. I added the proposal to the wiki here:
http://wiki.cocoondev.org/Wiki.jsp?page=ProductionInstallProposal
--- Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
...
> Instead of adding a production target, I'd suggest working on Timothy's
> instructions on the wiki (including the production.build.properties
> example) and adding the result to CVS as PRODUCTION-INSTALL.TXT or
> something once they're stabilized.
>
> -Bertrand
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [Proposal] Simple "production build" directions
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 28 aoû 2003, à 16:40 Europe/Zurich, Geoff Howard a écrit :
> ...Also, are there other config issues can be agreed on for this
> target/recommended setting? Logging level? Allow/Deny uploads?...
As someone mentioned, it might be hard or impossible to find a set of
settings that suits everybody.
Instead of adding a production target, I'd suggest working on Timothy's
instructions on the wiki (including the production.build.properties
example) and adding the result to CVS as PRODUCTION-INSTALL.TXT or
something once they're stabilized.
-Bertrand
Re: [Proposal] Simple "production build" directions
Posted by Timothy Larson <ti...@yahoo.com>.
Comments inline...
--- Geoff Howard <co...@leverageweb.com> wrote:
> Switching back to users, as the feedback we need is really for them.
...
> Timothy Larson wrote:
...
> > I lean toward a example properties file, because that introduces the
> > customization system that Cocoon uses.
...
> Ok, point well taken and I agree this will work the best. This is not
> really what was asked for orginally though -- will this be perceived as
> any better than the current state? The benefit is that the less-often
> modified properties will be removed from this file to reduce the shock
> of wading through so much that doesn't need to be understood. Still,
> I'll experiment with a build target that would load these defaults
> without the file-rename step which may scratch the other itch.
I see three possible problems with a source-only distribution: the user
not having an appropriate compiler, the user not wanting to wait for a
compile, and the shock to the user at having to compile at all.
With Java, having a appropriate compiler is not usually a problem.
Only a binary distribution can solve the compile-wait time. We can have
progress toward a binary distribution if we disentangle building jars from
configuring webapps, like Ralph suggests.
Your suggested build target could help with the "I have to configure and
compile?" shock, especially if we hid it in a script named "configure".
> >>Also, are there other config issues can be agreed on for this
> >>target/recommended setting? Logging level? Allow/Deny uploads?
Do you know any other big issues besides uploads and logging?
> > The default log level is already INFO, which is a reasonable default.
> > A default setting of Deny uploads is the most secure.
>
> I agree on the uploads, but INFO will really be too verbose for
> production for most people, don't you think? It will contain every
> component lookup, every step of every access, etc. Perhaps as
> developers we've too much treated INFO as FINE, but that's too late to
> change. I'd strongly suggest WARN or ERROR.
Lets pick one. Would WARN be appropriate?
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Proposal] Simple "production build" directions
Posted by Geoff Howard <co...@leverageweb.com>.
Switching back to users, as the feedback we need is really for them.
Any developers (besides me) interested please follow over there, and
whoever responds to this, please remove dev from the to: field.
Timothy Larson wrote:
> --- Geoff Howard <co...@leverageweb.com> wrote:
>
>>It will be easy to add a new build target "production-seed" (or
>>something to that effect) which would set those values and perform other
>>steps as needed. This would change the instructions to 1) edit blocks
>>properties 2) ./build.sh production-seed. Would that be better in your
>>mind, or is a sample properties better? I can see positives with both
>>solutions.
>
> I lean toward a example properties file, because that introduces the
> customization system that Cocoon uses. I updated to proposed text to
> refer to the "production.build.properties" as an example file:
>
> To make a production build without the documentation, samples, scratchpad,
> or deprecated code simply copy the example "production.build.properties"
> file to "local.build.properties" before going on to step 3.
> See below if you are rebuilding or wish to further customize the build.
Ok, point well taken and I agree this will work the best. This is not
really what was asked for orginally though -- will this be perceived as
any better than the current state? The benefit is that the less-often
modified properties will be removed from this file to reduce the shock
of wading through so much that doesn't need to be understood. Still,
I'll experiment with a build target that would load these defaults
without the file-rename step which may scratch the other itch.
>>The key is not how to accomplish it (because the pieces are already in
>>place in the build to do either), but _what_ to accomplish.
>
> The example "production build" does not have to be perfect for everybody,
> just reasonable and relatively secure. We already have the customization
> instructions for making it perfect.
>
>>Also, are there other config issues can be agreed on for this
>>target/recommended setting? Logging level? Allow/Deny uploads?
>
> The default log level is already INFO, which is a reasonable default.
> A default setting of Deny uploads is the most secure.
I agree on the uploads, but INFO will really be too verbose for
production for most people, don't you think? It will contain every
component lookup, every step of every access, etc. Perhaps as
developers we've too much treated INFO as FINE, but that's too late to
change. I'd strongly suggest WARN or ERROR.
> Perhaps we should add these two settings to the example production
> build properties file, since they are among the most likely to be
> customized:
>
> # ---- Configuration ----
> #config.enable-uploads=true
> # ---- Webapp Build Properties ----
> build.webapp.loglevel=INFO
Yes, that's the way to do it. The values can change as we come to
consensus of course.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Proposal] Simple "production build" directions
Posted by Geoff Howard <co...@leverageweb.com>.
Switching back to users, as the feedback we need is really for them.
Any developers (besides me) interested please follow over there, and
whoever responds to this, please remove dev from the to: field.
Timothy Larson wrote:
> --- Geoff Howard <co...@leverageweb.com> wrote:
>
>>It will be easy to add a new build target "production-seed" (or
>>something to that effect) which would set those values and perform other
>>steps as needed. This would change the instructions to 1) edit blocks
>>properties 2) ./build.sh production-seed. Would that be better in your
>>mind, or is a sample properties better? I can see positives with both
>>solutions.
>
> I lean toward a example properties file, because that introduces the
> customization system that Cocoon uses. I updated to proposed text to
> refer to the "production.build.properties" as an example file:
>
> To make a production build without the documentation, samples, scratchpad,
> or deprecated code simply copy the example "production.build.properties"
> file to "local.build.properties" before going on to step 3.
> See below if you are rebuilding or wish to further customize the build.
Ok, point well taken and I agree this will work the best. This is not
really what was asked for orginally though -- will this be perceived as
any better than the current state? The benefit is that the less-often
modified properties will be removed from this file to reduce the shock
of wading through so much that doesn't need to be understood. Still,
I'll experiment with a build target that would load these defaults
without the file-rename step which may scratch the other itch.
>>The key is not how to accomplish it (because the pieces are already in
>>place in the build to do either), but _what_ to accomplish.
>
> The example "production build" does not have to be perfect for everybody,
> just reasonable and relatively secure. We already have the customization
> instructions for making it perfect.
>
>>Also, are there other config issues can be agreed on for this
>>target/recommended setting? Logging level? Allow/Deny uploads?
>
> The default log level is already INFO, which is a reasonable default.
> A default setting of Deny uploads is the most secure.
I agree on the uploads, but INFO will really be too verbose for
production for most people, don't you think? It will contain every
component lookup, every step of every access, etc. Perhaps as
developers we've too much treated INFO as FINE, but that's too late to
change. I'd strongly suggest WARN or ERROR.
> Perhaps we should add these two settings to the example production
> build properties file, since they are among the most likely to be
> customized:
>
> # ---- Configuration ----
> #config.enable-uploads=true
> # ---- Webapp Build Properties ----
> build.webapp.loglevel=INFO
Yes, that's the way to do it. The values can change as we come to
consensus of course.
Geoff
Re: [Proposal] Simple "production build" directions
Posted by Steven Noels <st...@outerthought.org>.
Roger I Martin PhD wrote:
> Thanks Cocoon developers for thinking thru and working this out. It is much
> appreciated.
Your patience with us, poor human beings, is even more appreciated.
Cheers!
</Steven>
Re: [Proposal] Simple "production build" directions
Posted by Roger I Martin PhD <hy...@hypernexinc.com>.
Thanks Cocoon developers for thinking thru and working this out. It is much
appreciated.
--
Roger
----- Original Message -----
From: "Timothy Larson" <ti...@yahoo.com>
To: <de...@cocoon.apache.org>
Sent: Thursday, August 28, 2003 11:06 AM
Subject: Re: [Proposal] Simple "production build" directions
> --- Geoff Howard <co...@leverageweb.com> wrote:
> > It will be easy to add a new build target "production-seed" (or
> > something to that effect) which would set those values and perform other
> > steps as needed. This would change the instructions to 1) edit blocks
> > properties 2) ./build.sh production-seed. Would that be better in your
> > mind, or is a sample properties better? I can see positives with both
> > solutions.
>
> I lean toward a example properties file, because that introduces the
> customization system that Cocoon uses. I updated to proposed text to
> refer to the "production.build.properties" as an example file:
>
> To make a production build without the documentation, samples,
scratchpad,
> or deprecated code simply copy the example "production.build.properties"
> file to "local.build.properties" before going on to step 3.
> See below if you are rebuilding or wish to further customize the build.
>
> > The key is not how to accomplish it (because the pieces are already in
> > place in the build to do either), but _what_ to accomplish.
>
> The example "production build" does not have to be perfect for everybody,
> just reasonable and relatively secure. We already have the customization
> instructions for making it perfect.
>
> > Also, are there other config issues can be agreed on for this
> > target/recommended setting? Logging level? Allow/Deny uploads?
>
> The default log level is already INFO, which is a reasonable default.
> A default setting of Deny uploads is the most secure.
>
> Perhaps we should add these two settings to the example production
> build properties file, since they are among the most likely to be
> customized:
>
> # ---- Configuration ----
> #config.enable-uploads=true
> # ---- Webapp Build Properties ----
> build.webapp.loglevel=INFO
>
> --Tim Larson
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
Re: [Proposal] Simple "production build" directions
Posted by Timothy Larson <ti...@yahoo.com>.
--- Geoff Howard <co...@leverageweb.com> wrote:
> It will be easy to add a new build target "production-seed" (or
> something to that effect) which would set those values and perform other
> steps as needed. This would change the instructions to 1) edit blocks
> properties 2) ./build.sh production-seed. Would that be better in your
> mind, or is a sample properties better? I can see positives with both
> solutions.
I lean toward a example properties file, because that introduces the
customization system that Cocoon uses. I updated to proposed text to
refer to the "production.build.properties" as an example file:
To make a production build without the documentation, samples, scratchpad,
or deprecated code simply copy the example "production.build.properties"
file to "local.build.properties" before going on to step 3.
See below if you are rebuilding or wish to further customize the build.
> The key is not how to accomplish it (because the pieces are already in
> place in the build to do either), but _what_ to accomplish.
The example "production build" does not have to be perfect for everybody,
just reasonable and relatively secure. We already have the customization
instructions for making it perfect.
> Also, are there other config issues can be agreed on for this
> target/recommended setting? Logging level? Allow/Deny uploads?
The default log level is already INFO, which is a reasonable default.
A default setting of Deny uploads is the most secure.
Perhaps we should add these two settings to the example production
build properties file, since they are among the most likely to be
customized:
# ---- Configuration ----
#config.enable-uploads=true
# ---- Webapp Build Properties ----
build.webapp.loglevel=INFO
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [Proposal] Simple "production build" directions
Posted by Geoff Howard <co...@leverageweb.com>.
Timothy Larson wrote:
> --Simple proposal for a "production build" for Cocoon--
>
> Create a new file "production.build.properties,
> and refer to it in a new step 2 in INSTALL.txt:
>
> Proposed changes to "INSTALL.txt":
>
> (Insert a new step 2)
> 2) For a full build skip to step 3
>
> To make a production build without the documentation, samples, scratchpad,
> or deprecated code simply copy the file "production.build.properties"
> to "local.build.properties" before going on to step 3.
> See below if you are rebuilding or wish to further customize the build.
>
> (And, of course, renumber the following steps)
> 3) Build Cocoon by typing "build" or "./build.sh"
>
> 4) Run Cocoon by typing "cocoon servlet" or "./cocoon.sh servlet"
>
> 5) Open http://localhost:8888/ with your browser
>
> Proposed new file "production.build.properties":
>
> # ---- Webapp Exclusions ----
> exclude.webapp.documentation=true
> exclude.webapp.javadocs=true
> exclude.webapp.idldocs=true
> exclude.webapp.scratchpad=true
> exclude.webapp.samples=true
> # ---- Build Exclusions ----
> exclude.scratchpad=true
> exclude.deprecated=true
> exclude.javadocs=true
> exclude.idldocs=true
>
> How is this for a simple solution?
It will be easy to add a new build target "production-seed" (or
something to that effect) which would set those values and perform other
steps as needed. This would change the instructions to 1) edit blocks
properties 2) ./build.sh production-seed. Would that be better in your
mind, or is a sample properties better? I can see positives with both
solutions.
The key is not how to accomplish it (because the pieces are already in
place in the build to do either), but _what_ to accomplish.
Also, are there other config issues can be agreed on for this
target/recommended setting? Logging level? Allow/Deny uploads?
Geoff