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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
