cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon is not gump!
Date Tue, 29 Jun 2004 22:50:39 GMT
Sylvain Wallez wrote:

> 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).

This is a good point: even if we cannot reach consensus on having the 
code inside the jars, it should be *completely automatic* to have the 
build process do so and for every library that you choose your 
application to depend on.

In this regard, I would *strongly* suggest *NOT* to put that information 
in the library name, but in the gump.xml descriptor, so that even gump 
can use that information in the future (for example, acting as a nightly 
build system instead of a continous integration one).

-- 
Stefano.


Mime
View raw message