You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by Sam Ruby <ru...@apache.org> on 2003/01/05 23:35:27 UTC
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> 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.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> 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.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> 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.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> 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.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------