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: r170842 - in /gump/branches/Gump3
Date Thu, 26 May 2005 14:39:42 GMT
> > 1) Removed Homedir, since <home> isn't an output.
> Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of
> code projects find each other via a "prefix" directory. Step out of the
> confines of the java world :-)

I'm not thinking Java, I'm thinking Gump.[1] What you are describing is done
via properties [2].

That said, I'm game to come up with new ideas. With Gump2 I chose to emulate
behaviours, to fit with existing, not re-design. Heck, there was no real
expectation that Gump2 would live, let alone go TLP, so I hardly wanted to
freak out any commiters by changing all the metadata. That said, I'd like to
re-do the metadata for Gump3, and take whatever time we need on it.

> > 2) Added WorkItem and ResolvablePath.
> > 3) Added project.homedir - a ResolvablePath.
> > 4) Resolve outputs relative to the homedir.
> > 5) Zapped some tests.
> WHAT?!? Without reading on and knowing what this about (I see it has to do
> with removing Homedir), you really scared me :). We need more tests not
> less, and test removal really should be motivated well :-)

The tests (based upon mock objects, or where a project is a 'string') are
incredibly simple to write when Gump3 is simple, but as it gets fleshed out
the tests are less and less practical. I did some DynaGumper work yesterday,
but stumbled 'cos the tests could no longer be made to work 'cos they passed
in a string for a project, not an object. Basically, the unit test's
simplicity is in the way.

With Gump2 I had unit tests running models I loaded from pre-defined test
workspaces. That worked, but it made things more like an integration test,
not a unit test. I think we need to make a whole "mock model" (irrespective
of XML format) and have the unit tests be able to tap into these. I'd
appreciate some help here.

I removed those tests (and I sent an e-mail saying why, I thought) 'cos they
tested output objects that no longer existed as such.

Also, I want to do small/incremental commits, so we can view as we go. If
that sometimes breaks unit tests, and forces a discussion, thatis fine by

> > Modified: gump/branches/Gump3/pygump/python/gump/engine/
> ...
> >  from gump.model import *
> > +from gump.model.util import *
> We need to get rid of '*' imports. I just wish there was a tool in python
> automate "clean up imports".

I know, I'm not a fan either. I took a liberty and copied what was there.

> > +def _extract_relative_item(project, element):
> > +    """ Extract directory relative to module or project, based
> > +        upon which attribute  (parent or nested) is present."""
> IMHO this is a piece of logic that doesn't belong in the "objectifier". I
> guess that I believe the current gump object model has thoroughly messed
> directory management. I want to rethink it. I mean,
> > +    parent=element.getAttribute("parent")
> > +    nested=element.getAttribute("nested")
> > +
> > +    if parent:
> > +        rel_item=RelativePath(project.module,parent)
> > +    elif nested:
> > +        rel_item=RelativePath(project,nested)
> > +    else:
> > +        raise Error, "Unknown relative path entry (no parent or
nested): %s"
> > % (element)
> That's just ugly, right?

Do I have to mark #UGLY to let you know I know? ;-)

> > +    # Work Items
> > +    works = project_definition.getElementsByTagName("work")
> > +    for work in works:
> Similarly, <work/> is harmful and should be superfluous (we have it
> java will barf in the case of nonexistent directories on the classpath or
> remove them from the path permanently. The place to fix that is very close
> to the code that interfaces us to java, not in the model).

Yup, on platforms/builders (Ant on Solaris, I thinkl) we ought automatically
create "work" directories for the user/metadata, there ought not be an
element called <work/>.

> All this has nothing to do with the code you wrote, I'm just clearly
> realizing it now :)


> > Modified: gump/branches/Gump3/pygump/python/gump/model/
> ...
> > +        - homedir      -- None or a ResolvablePath (outputs are
relative to
> > this)
> See how confusing that is? At least it is to me!

And to me. Please do read [1] below, as it might explain how it came into

> ...
> > +class WorkItem(ModelObject):
> > +    """Model a directory containing stuff that can be used by other
> ...
> If its used by other projects then its an Output.
> > Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/
> ...
> > +        # Any internal build artifacts
> > +        for work in project.workitems:
> > +            self.classpath +=
> > ArtifactPath(,output.path.resolve(self.workdir))
> It really is a mess. We need to get rid of <work/>, <home/>, etc. What
> make sense is something like
> <repository name="ant">
>   <module name="ant">
>     <project name="ant">
>       <ant>
>         <classpath>
>           <directory="build/classes">
>         </classpath>
>       </ant>
>     </project>
>   </module>
> </repository>

I do like the idea of <classpath (for one, we'd know this was a Java Ant
project not another Ant project) and we could create the classpaths

> Or actually, we could probably extract the logic bits (and xml
> that work well from the way ant does all this, ie
> I understand now why it was so hard to get this right in previous versions
> of gump. The design is seriously broken. It probably makes sense when
> magically transforming xml into a bash script, but otherwise...

Hindsight is 20/20, and although I didn't write it, I do take "credit" for
perpetuating not improving. Thankfully we have Gump2 (heck, probably still
some Gump1s) working well (so there is broken, and broken broken ;-) and we
can take as much time, leveraging as many lessons as we can, to do Gump3.




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

View raw message