Upayavira wrote:
Carsten Ziegeler wrote:
Marc Portier wrote:No, these reasons aren't valid. In fact, I don't believe they ever were valid.
- I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no?
I guess as soon as we have real blocks we can switch to binary releases again if we want. But the reasons for recompiling are of course still valid.
there is a bit too much double negations for me to still grasp what is being said...
my opinion:
- recompiliation of your own extension code (not of cocoon) _is_ sensible with new releases of cocoon (regardless of how that is distributed) for only one reason: Even if we guarantee extension compatibility the compilation will yield deprecation warnings and signal where changes are to be foreseen.
We need a 'build' process, but not necessarily a 'compilation' process.
with 'we', you refer to cocoon application builders, right? (not the cocoon-dev group here)
I agree.
We could have a distribution that includes all of the jar files ready compiled. Then, when the user has unpacked this distribution, they edit their local.blocks.properties, etc, and run build, which prepares the webapp, copying only those precompiled jars across that are actually needed, and running the XConfPatch task, etc, etc.
absa! (would even like to see the jars distributed via maven or the like then)
I imagine this would be quicker for the user, and would probably result in a far smaller distribution.
Regards, Upayavira
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
