gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@apache.org>
Subject Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Date Sun, 05 Jan 2003 22:35:27 GMT
Leo Simons wrote:
> 
> If I have to do
> 
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
> 
> instead of
> 
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
> 
> well, I can live with that.   And if I can have the commands
> 
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml 
> 
> result in the same thing, what's left to complain about? :D

You posted is thought provoking.  Permit me to respond in kind.

The original intent of the project descriptors was that it be extensible 
in multiple directions.  Not only that a project descriptor could 
contain optional elements that would be ignored by some tools, but that 
tools like gump would intelligently "merge" multiple project definitions.

Example: a project definition for jakarta-avalon-db would say that it 
simply depends on *a* version of jakarta-regexp.  A jakarta-avalon 
profile could say that version 1.2 is preferred.  The LeoSimons 
workspace could say: no, not really, I want to use the version that I 
built on my hard drive.

Suppose centipede had a "gen" step that took a profile or workspace 
description and produced a single build.xml that could be run completely 
offline?

cvs co jakarta-avalon
centipede jakarta-avalon/profile.xml
ant jakarta-avalon/build.xml

Or, if you prefer, centipede could have options to "gen and run", or 
"run without regening".

Such profiles could even reference multiple projects, and could 
automatically build each in the correct order.

And power users could define workspaces that include multiple profiles, 
and provide override as appropriate.

- Sam Ruby




Mime
View raw message