Leo Simons wrote:
You posted is thought provoking. Permit me to respond in kind.
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
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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
