Timothy Larson wrote:
--- Geoff Howard <[EMAIL PROTECTED]> 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
