Much as I still have forrest issues with Python Gump, and some subtle working differences/failures, I think the core of Python Gump is there. I believe that the build on LSD is sound, just suffering from CVS servers issues, and again -- a few subtle differences that I can't put my finger on this moment. Since traditional gump was insensitive to CVS problems (I believe it failed to react to them) and Python Gump is ultra sensitive, I think much/most of the issues can be attributed to this. See: http://lsd.student.utwente.nl/gump/
I've made progress w/ Nick's "packages overriding real modules/projects" (I was incorrectly checking dependencies on packages) but I've more to do. See: http://gump.chalko.com/py/ As such, while I will keep hacking at bugs as I find them, I'd like to get Gump (and Sam/others) out of the manual package installation business... I'd like to discuss: * Gump calling Ruper (to install packages) * Gump producing a JAR Repository (for other subsidiary Gumps to feed off) I'll put some thoughts here, and if others have other/conflicting/additional thoughts maybe we could work on the Wiki. I am open minded, and game to implement pretty much anything. Anyways, my thoughts... * Gump calling Ruper: If we add an entry into a project [or module] descriptor (that is packaged) along the lines of: <repository id="maven" group="eclipse" /> .. and no CVS and no <ant|<script tags, we could have Gump use Ruper to download/synchronize the latest version at that repository with the version in the local package tree. Effectively this would keep a *single copy* of the *latest* of some package on the gump. This seems a nice balance, one only copy of non-Gumped projects, and the latest -- to keep folks for going stale. Other thoughts I have are along the lines of <project depend="x" version="1.2.3-alpha" combined with the above, to have folks be able to pick their version. This is doable [I believe], but more work and less "gumplike". *Gump producing a JAR Repository Along those lines, I am thinking that if Gump produced a "named hierarchical repository" (along the lines of what Jakarta infrastructure agree upon, I believe) we could have subsidiary gumps get "the latest package" from one or more upstream Gumps. I think this would make the lives of Nick/I (and other who run local Gumps) much easier, and save the OSS world a bunch of cycles. I know there is a can of worms with this, but I like the concept of a tree of Gumps all working together efficiently. I think we need more and more OSS projects to Gump, and I don't think that any one Gump site has resources for all that, but a tree might have. regards, Adam -- Experience Sybase Technology... http://www.try.sybase.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
