Antonio Gallardo wrote:
<snip/>
Having two files gives no guarantee that they are consistent, and allows clueless people to inadvertently delete the source archives just to purge useless files.Perhaps we can zip the in a separated file and point to them in eclipse. Same as we use the J2SDK source files. We just point to the separated file at:
file:/usr/java/j2sdk1.4.2_04/src.zip
They will can download (or recompile) it again ;-)
I'm sorry Antonio, but I think you missed the point. The problem when working with unreleased versions is that it is extremely difficult to know *what sources* were used for the build.
You can know when the build was done by looking at the class files creation date in the jars, but you cannot know what sources were used to produce them, except that they're older than the build. But how much older? Was the checkout done a day before or a week? Also, was it a full cvs update or only a partial one (e.g. on a particular block)?
That's the purpose of embedding the source in the jars: make the binary and its source a single and unique piece of information, with no means of having them out of sync except by modifying the content of the archive.
What if we make this the default _except_ for released versions? That way, people using a CVS snapshot will have the source files corresponding the binary they use at hand, whereas released versions won't have the extra size.
I like the oposite.
I think if someone is going to follow the CVS HEAD, he has enough skills to turn on an option if he wish.
Again you missed the point. This isn't needed for released versions as they can be fetched at will with no ambiguity from the official download area.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
