cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Binary release? (was Re: [vote] Versioning Guide)
Date Fri, 23 Apr 2004 09:26:01 GMT

Upayavira wrote:

> Carsten Ziegeler wrote:
>> Marc Portier wrote:
>>> - 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.
> No, these reasons aren't valid. In fact, I don't believe they ever were 
> 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, 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.

(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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message