RE: Binary release? (was Re: [vote] Versioning Guide)
Marc Portier wrote: > > 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. > As an application builder I don't agree :) You have these dump JDK incompatibilities (like you have in the famous StringBuffer). So, if you compile Cocoon with JDK 1.4 in 1.3 compatible mode, it's not 100% guaranteed that it will run on JDK 1.3 because of the incompatible changes! But on the other hand, if you're using JDK 1.4, you want to compile *everything* you can with 1.4. So what binary versions do you want to ship in the release? If you compile with 1.3, everyone using 1.4 is annoyed. And vice versa. And if 1.5 is available this will not get better I guess. So, in the end as an application builder I personally don't need binary releases. I see only a reason for binary releases: demoing (does this word exist?) Cocoon, so you simply download a binary war file, drop it into your webapp and see what Cocoon can do for you. Just my five euros :) Carsten
Re: Binary release? (was Re: [vote] Versioning Guide)
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 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 Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Binary release? (was Re: [vote] Versioning Guide)
On 23.04.2004 11:07, Upayavira wrote: We need a 'build' process, but not necessarily a 'compilation' process. 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. So nice this sounds, so bad it can be for the users. They might select blocks missing their dependencies (because we have not maintained them correctly, or they did a mistake when selecting them) and got NoClassDefFoundError at run time. Joerg
Binary release? (was Re: [vote] Versioning Guide)
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. We need a 'build' process, but not necessarily a 'compilation' process. 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. I imagine this would be quicker for the user, and would probably result in a far smaller distribution. Regards, Upayavira
