gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: svn commit: r170825 - in /gump/branches/Gump3
Date Thu, 26 May 2005 15:00:27 GMT

> > 1) Added to the tsws1.xml workspace:
> Which is? That info should not be in the commit but rather in the xml
> comments for the workspace.
It is a hostname I've used for a couple of years. It is just like
giraffe.xml, I assume, although I suspected that was some new Python module
(like cheetah ;-) for a while. :-)

> > 2) Worked on the AntBuilder. Seems closer to providing the needs of the
> > commandline. Still need to add <work> items to the Gump3 model complete
> I can see what you worked /on/ from easily enough. But what's the work
> you /did/?

Sorry, I thoguht that was what the code diff was for, so I summarized. I
made the Ant commandline/environment match what was needed. I added
CLASSPATH and an environment variable, I added -X bootclasspath/p for boot
classpath, I call java (searching on the $PATH, not fixing it), I
added -buildfile and

The biggest work was to make classpath entries relative to the <home/>
element's nested or parent path, releative to the project directory. This
mean resolving all such entries at time of use, since the model was "pure"
of  the root "workdir". Trust me, it wasn't fun, but I'm not 100% certain it
is all wrong.

Maybe this is something we can discuss on irc://
some time. I'd love for Stefan to be there, 'cos he knows the metadata (use
cases) the best. Other than that, I'm open to ideas on how to resolve

> > +                self.method(project, command)
> > +            except Exception:
> > +                self.log.exception("Command %s Failed..." % (command))
> > +                command.build_exit_status=1
> > +
> You're "swallowing an exception" here. Don't ever swallow exceptions. I
> think we had a thread on that already recently. Who knows, it might be
> changed again already :-)

I was trying to follow the "protocol" at the highest point I could do it.
This was the only place that was (1) build related (2) able to catch
exceptions. If you've pushed this into some algorythm, then great, but I
guess that assumes that all exceptions thrown from project visits are build
related, right? That seems off.

> ...
> > Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/
> ...
> > -class BuilderPlugin(AbstractPlugin):
> ...
> Hey, where'd that go?

We had two, with little/no specializations, I returned them one.

> I'm guessing that what makes this so painful (besides the classpath
> being painful in general) is the use of "intelligent objects". You'll note
> that so far the objects I've put into the gump model are very "dumb". I.e.
> The "javabeans pattern" is avoided. I don't know who thought of javabeans,
> but they were wrong.

Does this hark back to your "small classes, many functions" e-mail? If so,
I'll re-read that.

> > +        # Clone the environment, so we can squirt CLASSPATH into it.
> > +        self.tmp_env = dict(os.environ)
> I don't get it. Why is this done here? The problem with the above is that
> the plugin suddenly has a "tmp_env" variable, and when and how will that
> cleaned up? I believe you could ultimately even consider

How is this different from DynaGumper holding a log variable, or a db
variable, or whatever. Plugins re-use things over and over again, when not
store them? Sicne we don't ahve a 'reaper' it could be cleaned up either (1)
on exit [like most of our stuff] or (2) in _finalize.

Thanks for taking time to review this. I do appreciate the input/different
perspective, even if the volume of it is hard to accept at times. ;-)



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message