Re: [Proposal] Simple "production build" directions

[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

[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