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" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
