Yes, this makes sense. I ran into the same thing with 2.1.4 because I patched our copy and submitted the patches (which are now in 2.1.5). I did have trouble finding a home for the patches because we don't keep Cocoon in our CVS.

However, I still think this is a good idea for snapshot jars that Cocoon includes. I't's been a pain finding some of the source code for those in the past.

Ralph

At 6/9/2004  12:48 AM, you wrote:

Ok, I think not to have explained the use case clearly. It is actually very close to what you explain about dependent projects. This feature is not useful for us Cocoon devs, but for project developpers that use unreleased versions.

We have a project here in my company with complex recursive forms which required me to extend CForms. I do not work directly on the project, but provide its developpers with new versions of forms-block.jar that run with the official 2.1.5. The purpose of including the sources in jar files is for the developpers of this project to be able to know with no ambiguity what sources they use. Furthermore when these sources are not yet in Cocoon's CVS (don't worry, commits will come soon).

These guys are in the office next to mine, so roundtrip time is fast and communication easy. Now consider a project made for a remote customer, which required to use a non-released version because of a bug to fix or a few feature to implement. One year after the project is finished, the customer calls back because some errors occur. How do you know what sources the project actually uses? Just ask the customer to send you the contents of WEB-INF/lib!

So, to restate it, this feature is of little use for us Cocoon devs but very useful for users of CVS snapshots. It's just useful for them as it would be useful for us to have source of snapshots of dependent projects in the corresponding jars.

Does it make more sense?

Sylvain



Reply via email to