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?
A decompiler will be your best friend, not google. Google might give you the solution, but without the code how to you change it? re-assemblying the bytecode by hand?
Or you might want to kiss Sylvain if the source code was distributed along with the binary code ;-)
When I say "along" it doesn't mean "inside", even if I completely agree with Sylvain that having the code inside with the bytecode in the jar makes the most natural sense.
Carsten is afraid of having to deploy a few more Mb of stuff, I think the first time he is hit by the above scenario he'll change his mind rather quickly and a few Mb will not be such a big deal of a price to pay to sleep well at night.
My point is: do *not* make the assumption that the CVS will be there when you need it. It won't be. Solid working software has the tendency to work for decades before requiring fixes. And people have a tendency to change jobs, ideas and interests much faster than working software requires fixes.
And information has a notoriously bad habit of getting corrupted, or lost and people (including myslelf!) have a notoriously bad habit of still considering digital storage capacity as a scarce resource and are maniacs of cleaning up and very bad at forecasting the need for information that today appears useless.
I guess that working in a library does change your perspectives on those things a little bit ;-)
Especially when your boss sings the digital preservation anthem every other day ;-) [and for a good reason, I must say!]
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
