Stefano Mazzocchi wrote:
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).
Well, do you deliver gump.xml with your project? No. If we don't include the source in jars, we must at least be able to reach them unambiguously just from that single jar file. Either through additional manifest files stored in it, or - and this is the most simple way - through the filename (provided of course that it's kept unchanged).
Furthermore, I'm not sure putting this information in gump.xml is necessary to perform nightly builds, as each project's build.xml should theroretically be able to do that build, either using dependencies included in the project itself or by fetching them from a remote repository. Reproduceability of the build is also a key aspect of software maintainance, and the OSS community has for long understood this because of its wide geographical distribution and its lazyness to answer FAQs ;-)
I haven't looked at what is in gump.xml, but I'm reticent with just going with a naming standard. While jars.xml does point you to a project's website, it doesn't point you to the cvs repository. Second, blocks don't seem to have the equivalent of jars.xml so one is left guessing as to where to find the project that owns the jar.
Frankly, this is where maven would really help as all these jars would not be included with the Cocoon distribution but be coming from a central repository. It would then be just as easy to put a jar of the source in the repository as the binary jar. This would make the problem just disappear. Each block's project.xml would just reference the jar and version. And, of course, this would make Cocoon's distribution much smaller. I understand the resistance to using maven, but if it is not used I would suggest that Cocoon needs to reinvent at least this part of it.
Ralph
