gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: Using Gump to find configurations
Date Tue, 02 Dec 2003 20:18:12 GMT
Denis

This is great feedback, thanks. I kinda ran out of steam when it came to
cross referencing, and only skimmed statistics.

Yeah, I was messing around w/ modules not projects to keep the pages small.
Nobody has liked it (not sure even me). I think moving to projects would be
smart.

Basically, to update these things (1) edit the gump/output/statsdb.py and
gump/output/xref.py classes (2) edit the gump/documentation/forrest.py
module (at the bottom).

If you know Java/Perl you can't handle this Python stuff. It is kinda fun,
so long as you don't have to do 8 hour builds to crap out on one line -- 
that is as painful. Thankfully we now have some simple unit tests (including
for stats and xref).

If you get itch/time to help, please do. Post questions/patches here.

regards

Adam
----- Original Message ----- 
From: "Denis Ranger" <dranger@optonline.net>
To: "Gump code and data" <gump@jakarta.apache.org>
Sent: Monday, December 01, 2003 7:29 PM
Subject: Re: Using Gump to find configurations


> Adam,
>
> > I am curious, do you use Gump for cross referincing only, or for Gumping
> > builds? If cross referencing, why would you not use:
>
> Let me clarify. I use gump as a tool for building the jars that I need in
the context of a
> project in particular. For example on one project, I had to used a
third-party library
> which required particular versions of log4j, xerces and xalan. So, add the
things I
> needed to the pot and figure out what else I need (and only that). Once I
have that
> profile, of course, the fun begins and I have to actually build the thing.
This may
> require reverting some modules to prior versions (not necessary the
latest). When I
> get a successful build, I have a *configuration* that ensures I won't be
having any
> weird LinkageErrors due to jar incompatibilities, thus being able to sleep
better at
> night...
>
> What I'm doing now is trying to formalize and instrumentize what I've been
doing in
> an adhoc fashion before (especially since that will be part of my
responsabilities in
> the team I'm about to join).
>
> > http://gump.covalent.com/log/xref.html
>
> Uh... I did the script exactly to avoid manually wading through the
otherwise nice and
> useful global xref...
>
> > Could you give me ideas of what you'd like to see here:
> >
> > http://lsd.student.utwente.nl/gump/gump_xref/index.html
> > http://lsd.student.utwente.nl/gump/gump_xref/repo_module.html
>
> Ok... a few comments, in no particular order:
>
>  - I use the global index and stats only when I'm trying to select which
OS project is
> appropriate (hey, not all xml serializers are created equals...).
>
>  - Stats and Xref... I would prefer an integrated view, like here's all I
know about
> repository X or module Y, or project Z. It would make it more of an
invaluable tool
> when evaluating which java open-source projects to use (already is...)
>
>  - I marginally care about *where* a project is stored (repository,
module...)  I did at
> some point, though... I seem to recall trying to avoid SourceForge due to
all the
> connection problems I had to their CVS (better now). It would be nice to
have some
> stats about that (connection success/failure rate, lag time)
>
>  - I like the FOG factor, although individual numbers and a formula
reminder would
> be useful (for google-impaired users...)  Some other measures of stability
would be
> nice too.
>
>  - stats/xrefs by projects are more useful to me than per modules. For
example, while
> it's nice to know that the jakarta-commons module is used so much, it
would be more
> useful to know that it's actually commons-logging that's fashionable (for
example)
>
> - A measure of how far from gumpland a project is would be useful: how
many
> external packages it uses or includes. Is it a new-born project or a
well-established
> one? It tend to favor things I can see and build myself. Well-used
projects are also
> more sellable to clients/collegues.
>
> > If for Gumping builds, isn't there a Maven thing called 'reactor' or
> > something? Does that not work for you?
>
> The reactor is useful if you are building subprojects from a master one.
It also
> assumes that you will be using the latest version, that the subproject is
also
> mavenized. This doesn't work for me because once I get the jars of a
workable
> configuration, I can pretty much forget about the sources (not docs).
>
> > BTW: The Python version of Gump takes a "project expression" (comma
> > separated list of exrepessions with wildcards) to specify what project
to
> > work on. Right now if passed to build.py it builds those projects, and
those
> > below (a full stack). I've been thinking about having Gumpy write a
profile
> > (for a build stack) or have the GUI generate one. Ought be simpel to
add. If
> > you happen to be interested in there, I'd appreciate the help w/
> > development, but this is Python (easy sometimes) not XSLT. Game?
>
> To be honest, I never really looked at the python aspects of gump,
probably because I
> never bothered to learn python... I'm more of a java, perl, php person
nowadays... I'm
> sure I can handle it... (I dropped any mentions to C in my resume over 10
years ago,
> old compiler-guy-is-me)  I'll have a look at it, just to humor you... Not
promising
> anything  ;)
>
>  --
>  Denis Ranger
>


Mime
View raw message