gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Ranger <dran...@optonline.net>
Subject Re: Using Gump to find configurations
Date Tue, 02 Dec 2003 02:29:42 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message