Distributed Gumps

["Adam R. B. Jack" <aj...@trysybase.com>]

As I (bit by bit) put Python Gump back together & work out the little issues
generated by the re-work, I want to start thinking about next steps. Having
xdoc output & pretty forrest sites (btw: thanks for the blue background logo
Nicola) isn't meant to be the goal, just a feature. Since Gumpy is more OO,
I wish to leverage that to do something seriously useful, above and beyond
what could've been done before.

That all said, Gump is an information communicator, so requests for
improvements on the presentation (see http://lsd.student.utwente.nl/gump/)
are welcomed. [Note: I've added repository lists, XML definitions on the key
objects, and started on cross reference information. Also, the RSS feed
ought be less verbose now also, using the statistics database to only
publish the first time a state changes.]

BTW: gump.dotnot.org is down right now, Python Gump wasn't playing nicely w/
the OS. Strangely this doesn't happen on LSD (Py 2.2.1), or Chalko (Py
2.2.2), or others, so I'm hoping it is the instance of the Python install on
dotnot (2.2.3) & that an upgrade will help out. Maybe a stab with Python
2.3.

BTW: Other side tasks -- (1) update cvs.apache.org to stop pointing to old
data (2) work to get gump.apache.org on moof [assuming no Linux box gets
offered up] (3) update documentation (4) start nagging [I'll ask here
first].

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

Even though it introduces interesting issues, I feel that this is a way
(perhaps better than a GUI) to get Gump out to more places, to get more
projects Gumping. The goal being better Gump coverage of OSS, the goal being
more successful collaborations & deeper [yet stable] OSS stacks.

Not that this is a new topic, but what are folks thoughts on this?
Worthwhile? Nuts? Any implementation pointers/thoughts?

Thanks in advance.

regards,

Adam
--
Experience Sybase Technology...
http://www.try.sybase.com

Re: Cascading Gumps ( was Re: Distributed Gumps )

[Nick Chalko <ni...@chalko.com>]

Excelent Idea.  I thnik this could really increase the number of 
indepent gumps.



Adam R. B. Jack wrote:

>Ok, adding SVN (repository with type='svn' as opposed to type='cvs') made me
>realize we could add a repository with type='jars'. Such a repository would
>be a structured jars repository (e.g. http://gump.dotnot.org/repository)
>perhaps produced by an upstream Gump.
>
>The module descript could have a <jars element, just like we have <cvs and
><svn today, and could give the information needed in order to download the
>[latest] jars from that repository. Once downloaded a module could be deamed
>'packaged' if all it's projects outputs were then found on the disk.
>
>Having this approach seems to fit quite nicely with what exists inside Gump
>today, and seems easy to code. Bascially it does restrict each module to
>'coming from a known repository' (not any group of repositories upstream)
>but that is livable, maybe better. It does meant the workspace/module
>metadata needs to be modified (kinda like with packages today) but I think
>that a few trailing entries (like next), like we do for packages, are not
>too painful:
>
>    <module name='abc' jars='repository1'>
>
>Thoughts?
>
>regards,
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Cascading Gumps ( was Re: Distributed Gumps )

["Adam R. B. Jack" <aj...@trysybase.com>]

Ok, adding SVN (repository with type='svn' as opposed to type='cvs') made me
realize we could add a repository with type='jars'. Such a repository would
be a structured jars repository (e.g. http://gump.dotnot.org/repository)
perhaps produced by an upstream Gump.

The module descript could have a <jars element, just like we have <cvs and
<svn today, and could give the information needed in order to download the
[latest] jars from that repository. Once downloaded a module could be deamed
'packaged' if all it's projects outputs were then found on the disk.

Having this approach seems to fit quite nicely with what exists inside Gump
today, and seems easy to code. Bascially it does restrict each module to
'coming from a known repository' (not any group of repositories upstream)
but that is livable, maybe better. It does meant the workspace/module
metadata needs to be modified (kinda like with packages today) but I think
that a few trailing entries (like next), like we do for packages, are not
too painful:

    <module name='abc' jars='repository1'>

Thoughts?

regards,

Adam

Re: Distributed Gumps

["Adam R. B. Jack" <aj...@trysybase.com>]

> 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
repository@apache.org) 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

Re: *Unset* / Axis

["Adam R. B. Jack" <aj...@trysybase.com>]

> I was just browsing ws-axis' output
>
(http://lsd.student.utwente.nl/gump/ws-axis/work/build_ws-axis_ws-axis.html)
and found that the
> build failed because log4j-core.jar was set to "*Unset*" (property.py -
line 72). Can you please
> use an empty string instead?

I noticed that too, it led to a bunch of fixes for property resolving today.
Basically, though, *Unset* was meant to get noticed and '' probably
wouldn't. That said, I ought be handling property resolving errors better
than hacking the value. Give me a little while to dig into a better
solution.

regards

Adam

*Unset* / Axis

[Davanum Srinivas <di...@yahoo.com>]

Adam,

I was just browsing ws-axis' output
(http://lsd.student.utwente.nl/gump/ws-axis/work/build_ws-axis_ws-axis.html) and found that the
build failed because log4j-core.jar was set to "*Unset*" (property.py - line 72). Can you please
use an empty string instead? 

thanks,
dims

=====
Davanum Srinivas - http://webservices.apache.org/~dims/