cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon is not gump!
Date Wed, 30 Jun 2004 07:01:55 GMT
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>> Sylvain Wallez wrote:
> <snip/>
>>> 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).
>> This is a good point: even if we cannot reach consensus on having the 
>> code inside the jars, it should be *completely automatic* to have the 
>> build process do so and for every library that you choose your 
>> application to depend on.
>> 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).

My point is: in order to allow those who want to generate their cocoon 
with all the sources included in the libraries, you need a timestamp/tag 
and a CVS repository description for every library.

instead of placing the CVS timestamp in the library name and the CVS 
location alongside, place it in the gump descriptor which is a much more 
natural place for that metadata to be and much more useful.

> 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 ;-)

gump builds against the very last checkout, it has no (yet) the notion 
of a regression to a required tag/timestamp and it's work that is in my 
todo list because it will be able to identify blame in broken 
dependencies with a lot more precision.


View raw message