> So, I'm thinking next steps, and "distributed gumps" is still the hot
> favourite. This could been seen a few ways, but I interpret it as
cascading
> gumps to save on cycles. In effect, one Gump would "reach up and borrow" a
> latest set of outputs (jars) from another. This brings in some interesting
> issues, like timing and what if the "latest" from another Gump isn't 100%
> the latest (due to a build failure or ongoing compile), and so forth. It
> also brings up the idea of "collections of Gump metadata" (distributing
that
> in chunks.)

Ok, (1) you are all probably at or involved w/ ApacheCon (2) I didn't
explain this idea. Let me elaborate.

I hate seeing packages installed for main Gump, worse (for lowly folks like
me w/o the local resources of a mega Gump, or without the patience for a
full stack build) I hate installing packages over descriptors (1) 'cos this
is stale (2) 'cos the descriptor changes & the Gump breaks. Basically, I'd
like to remove these chores.

I see a cascade of peer Gumps. Take LSD, DotNot, all building the main
projects, and generating jar outputs. [See
http://gump.dotnot.org/repository/]. These Gumps are peers within the first
tier. What if subordinate Gumps (perhaps Gumping personal projects, perhaps
Gumping more SF.net projects or codehaus.org or whatever) downloaded the
'latest' jars from one of those upper tier Gumps instead of building them.
Their cycles could be spent on their projects, so maybe allowing more Gump
runs a day, or more projects to be Gumped, etc. Their generated result could
be published into a repository, to allow further downstream Gumps. Teirs at
lower levels could pluck from any of their higher peers.

Basically Ruper (or whatever survives/developes as a result of
[EMAIL PROTECTED]) is in the business of downloading stuff from
repositories (and getting the latest, and cleaning up older local copies).
This could be used to cache local copies from remote Gumps (downloading via
HTTP). Gump could calculate classpath from this cache, just like it does
with packages, heck in all aspects (other than manual installtion) these
things are packages.

So, that's the thinking. Do you think this is interesting to folks, do you
think this is a step in the right direction for Gump?

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to