cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon is not gump!
Date Tue, 29 Jun 2004 21:53:01 GMT
Stefano Mazzocchi wrote:

> Antonio Gallardo wrote:
>> I don't talked about forking. My POV is, why to see the code? It is not
>> enough to know that a 3rd party lib is broken. Contact the right 
>> community
>> and check if there is already a patch for the problem? IMHO it is easier
>> than debug it yourself. The chances a fix is there is very high.
>> I often prefer to google for a bug before starting to wet my hands. 
>> Maybe
>> I am very lazy! ;-)
> hmmm, consider this scenario: you are asked to build a system, say, 
> for the government, that has to support the pension system or the IRS.
> This cocoon application was built out of an official release, 
> everything documented, legally certified, all text written and such.
> This application runs for 15 years, then, one day, a change in the 
> underlying dependencies (java or whatever) affects it in such a way 
> that it can no longer work.
> You are hired again to fix it.
> You find out that this "jurassic" cocoon version depends on 
> technologies that are no longer available, their communities folded, 
> the CVS archived or lost in a disk crash or in OSDN bankrupcy.
> What do you do?

I spent 10 years in the space industry, and worked some satellite 
control systems that require maintainance to be possible for 15 years! 
And I actually had to work in 1999 on a software I wrote in 1991 to fix 
some Y2K bugs.

In this kind of situation, there is a very heavy process set up to 
ensure that *all* source code is available, as long as *all* tools and 
operating systems required to build and run the software. Plus a huge 
amount of design and test documents to allow people to dive in years 
after the original development team has disappeared.

The current situation is a bit different, but comes from my own 
experience of using unreleased Cocoon on some projects. Sure, it's not 
the usual case to deploy a non-official version, but being a committer 
here, I often add new features to Cocoon because they are needed by the 
projects I'm working on. And I can't wait for these changes to be 
included in an official version to deliver the project to the customer. 
This has the consequence that I must have an easy way to get back the 
source in case of problems. And where is the best place to store the 
code of opensource software? In the software itself! Hence the 
-Dinclude.source-in-jars build flag and the idea to include source of 
unreleased 3rd party jars in the jars themselves.

Now it seem not everybody agrees with or understand these concerns. 
Those who do will use -Dinclude.source-in-jars when building their 
unofficial distros, and will fetch 3rd party sources using the timestamp 
included in the library name (can even be automated using a script).


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message