You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@gump.apache.org by aj...@apache.org on 2005/05/19 01:26:27 UTC
svn commit: r170842 - in /gump/branches/Gump3/pygump/python/gump:
engine/objectifier.py model/__init__.py plugins/java/builder.py
test/testModel.py
Author: ajack
Date: Wed May 18 16:26:26 2005
New Revision: 170842
URL: http://svn.apache.org/viewcvs?rev=170842&view=rev
Log:
1) Removed Homedir, since <home> isn't an output.
2) Added WorkItem and ResolvablePath.
3) Added project.homedir - a ResolvablePath.
4) Resolve outputs relative to the homedir.
5) Zapped some tests.
Modified:
gump/branches/Gump3/pygump/python/gump/engine/objectifier.py
gump/branches/Gump3/pygump/python/gump/model/__init__.py
gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py
gump/branches/Gump3/pygump/python/gump/test/testModel.py
Modified: gump/branches/Gump3/pygump/python/gump/engine/objectifier.py
URL: http://svn.apache.org/viewcvs/gump/branches/Gump3/pygump/python/gump/engine/objectifier.py?rev=170842&r1=170841&r2=170842&view=diff
==============================================================================
--- gump/branches/Gump3/pygump/python/gump/engine/objectifier.py (original)
+++ gump/branches/Gump3/pygump/python/gump/engine/objectifier.py Wed May 18 16:26:26 2005
@@ -27,6 +27,7 @@
from xml.dom import minidom
from gump.model import *
+from gump.model.util import *
from gump.engine import EngineError
from gump.engine.modeller import _find_element_text
@@ -216,20 +217,41 @@
project.add_command(Ant(project, name, target, buildfile))
#TODO
+def _extract_relative_item(project, element):
+ """ Extract directory relative to module or project, based
+ upon which attribute (parent or nested) is present."""
+ 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)
+
+ return rel_item
+
+def _create_artifacts(project, project_definition):
+
+ # Work Items
+ works = project_definition.getElementsByTagName("work")
+ for work in works:
+ project.add_output(WorkItem(project,_extract_relative_item(project,work)))
-def _create_outputs(project, project_definition):
+ # Home Directory (outputs are relative to this)
homes = project_definition.getElementsByTagName("home")
if homes.length > 0:
- home = homes.item(0).getAttribute("directory")
- project.add_output(Homedir(project,home))
+ project.homedir = _extract_relative_item(project,homes.item(0))
+ # Outputs
jars = project_definition.getElementsByTagName("jar")
for jar in jars:
name = jar.getAttribute("name")
id = jar.getAttribute("id")
add_to_bootclass_path = jar.getAttribute("type") == "boot"
project.add_output(Jar(project,name,id,add_to_bootclass_path))
-
+
#TODO more outputs
@@ -384,7 +406,7 @@
workspace.projects[project.name] = project
_create_commands(project, project_definition)
- _create_outputs(project, project_definition)
+ _create_artifacts(project, project_definition)
# wire up dependencies only after projects have been created
for project_definition in project_definitions:
Modified: gump/branches/Gump3/pygump/python/gump/model/__init__.py
URL: http://svn.apache.org/viewcvs/gump/branches/Gump3/pygump/python/gump/model/__init__.py?rev=170842&r1=170841&r2=170842&view=diff
==============================================================================
--- gump/branches/Gump3/pygump/python/gump/model/__init__.py (original)
+++ gump/branches/Gump3/pygump/python/gump/model/__init__.py Wed May 18 16:26:26 2005
@@ -19,6 +19,7 @@
__copyright__ = "Copyright (c) 2004-2005 The Apache Software Foundation"
__license__ = "http://www.apache.org/licenses/LICENSE-2.0"
+
class Error(Exception):
"""Generic error thrown for all internal model module exceptions."""
pass
@@ -270,8 +271,11 @@
projects depend on this project
- commands -- ordered list of Commands instances that need to be
executed to build this project
+ - homedir -- None or a ResolvablePath (outputs are relative to this)
- outputs -- list of Output instances describing what results a
build of this project results in
+ - workitems -- list of WorkItem instances describing what directories/files
+ are used during the build of this project.
"""
#TODO nice string representations of the entire model
#def __str__(self):
@@ -284,11 +288,13 @@
self.module = module
self.name = name
self.path = path
+ self.homedir = None
self.dependencies=[]
self.dependees=[]
self.commands=[]
self.outputs=[]
+ self.workitems=[]
def add_dependency(self, relationship):
assert isinstance(relationship, Dependency)
@@ -336,6 +342,10 @@
def add_output(self, output):
assert isinstance(output, Output)
self.outputs.append(output)
+
+ def add_work(self,work):
+ assert isinstance(work,WorkItem)
+ selfd.works.append(work)
DEPENDENCY_INHERIT_NONE = "none"
DEPENDENCY_INHERIT_RUNTIME = "runtime"
@@ -514,7 +524,42 @@
#TODO: more Commands
-OUTPUT_ID_HOME = "homedir"
+class RelativePath(ModelObject):
+ def __init__(self,model,path):
+ assert isinstance(model, ModelObject)
+ assert isinstance(path, basestring)
+ self.model = model
+ self.path = path
+
+ def resolve(self,workdir):
+ from gump.model.util import get_module_directory,get_project_directory
+ if isinstance(self.model,Module):
+ base=get_module_directory(workdir,self.model)
+ elif isinstance(self.model,Project):
+ base=get_project_directory(workdir,self.model)
+ else:
+ pass #TODO Raise?
+ import os.path
+ return os.path.join(base,self.path)
+
+ def __str__(self):
+ return "RelativePath:%s:%s" % (self.model,self.path)
+
+class WorkItem(ModelObject):
+ """Model a directory containing stuff that can be used by other projects.
+
+ Has the following properties:
+
+ - project -- the containing project.
+ - path -- the path to the directory or file.
+ """
+ def __init__(self, project, path):
+ assert isinstance(path, RelativePath)
+ self.project = project
+ self.path = path
+
+ def __str__(self):
+ return "<WorkItem:%s>" % (self.path)
class Output(ModelObject):
"""Model an output, something a successful project build will yield.
@@ -534,24 +579,7 @@
def __str__(self):
return "<Output:%s>" % self.id
-
-class Homedir(Output):
- """Model a directory containing stuff that can be used by other projects.
-
- Has the following properties:
-
- - all the properties an Output has
- - directory -- the directory that should be exported as this project
- its homedirectory
- """
- def __init__(self, project, directory):
- assert isinstance(directory, basestring)
- Output.__init__(self, project, OUTPUT_ID_HOME)
- self.directory = directory
- def __str__(self):
- return "<Homedir:%s>" % self.directory
-
class Jar(Output):
"""Model a java archive that can be used by other projects.
Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py
URL: http://svn.apache.org/viewcvs/gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py?rev=170842&r1=170841&r2=170842&view=diff
==============================================================================
--- gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py (original)
+++ gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py Wed May 18 16:26:26 2005
@@ -21,8 +21,8 @@
import sys
from os.path import abspath, join, isfile
-from gump.model import Script, Error, Project, Ant, Dependency, Homedir, Jar
-from gump.model.util import get_project_directory
+from gump.model import Script, Error, Project, Ant, Dependency, WorkItem, Jar
+from gump.model.util import get_project_directory,get_module_directory
from gump.plugins import AbstractPlugin
from gump.plugins.builder import BuilderPlugin
from gump.util.executor import Popen, PIPE, STDOUT
@@ -97,9 +97,11 @@
def _calculateClasspaths(self, project, ant):
"""Generate the classpath lists"""
#TODO This ought be under "java" not under "Ant".
-
- #TODO Need "<work> elements
-
+
+ # Any internal build artifacts
+ for work in project.workitems:
+ self.classpath += ArtifactPath(work.name,output.path.resolve(self.workdir))
+
# Recurse into dependencies
visited=[]
for dependency in project.dependencies:
@@ -113,7 +115,10 @@
# Access the players
project=dependency.dependency
- projectpath = get_project_directory(self.workdir,project)
+ projectpath=get_project_directory(self.workdir,project)
+ if project.homedir:
+ projectpath = project.homedir.resolve(self.workdir)
+ self.log.debug('Project HomeDir : %s' % projectpath)
#TODO Do we need a filter here? Are all dependency infos
# appropriate, or not?
@@ -149,16 +154,14 @@
if (not ids) or (output.id in ids):
if ids: depend_str += ' ID = ' + output.id
- if isinstance(output,Homedir):
- path = os.path.join(projectpath,output.directory)
- elif isinstance(output,Jar):
+ if isinstance(output,Jar):
path = os.path.join(projectpath,output.name)
else:
raise Error, "Unknown Output Type for %s: %s" % (self.__class__.__name__, output.__class__.__name__)
- self.log.debug('Contribution : %s' % path)
artifact_path=ArtifactPath(output.id,path,depend_str)
-
+ self.log.debug('Contribution : %s' % artifact_path)
+
# Add to CLASSPATH (or BOOTCLASSPATH)
if not isinstance(output,Jar) or not output.add_to_bootclass_path:
ant.classpath += artifact_path
@@ -200,9 +203,7 @@
def __init__(self,workdir, log):
BuilderPlugin.__init__(self, workdir, log, Ant, self._resolve_classpaths)
- def _resolve_classpaths(self, project, ant):
-
- projectpath = get_project_directory(self.workdir,project)
+ def _resolve_classpaths(self, project, ant):
self._resolve_classpath(ant.classpath)
self._resolve_classpath(ant.boot_classpath)
Modified: gump/branches/Gump3/pygump/python/gump/test/testModel.py
URL: http://svn.apache.org/viewcvs/gump/branches/Gump3/pygump/python/gump/test/testModel.py?rev=170842&r1=170841&r2=170842&view=diff
==============================================================================
--- gump/branches/Gump3/pygump/python/gump/test/testModel.py (original)
+++ gump/branches/Gump3/pygump/python/gump/test/testModel.py Wed May 18 16:26:26 2005
@@ -38,8 +38,7 @@
from gump.model import Mkdir
from gump.model import Rmdir
from gump.model import Script
-from gump.model import Homedir
-from gump.model import OUTPUT_ID_HOME
+from gump.model import WorkItem
from gump.model import Jar
class ModelTestCase(TestCase):
@@ -547,27 +546,7 @@
o = Output(p)
self.assertEqual(p,o.project)
self.assertRaises(AssertionError,Output,None)
- self.assertRaises(AssertionError,Output,"someproject")
-
- def test_homedir(self):
- wname = "blah"
- w = Workspace(wname)
- rname = "booh"
- r = Repository(w,rname)
- mname = "bweh"
- m = Module(r,mname)
- pname = "bwop"
- p = Project(m,pname)
-
- dir = "some/dir"
- o = Homedir(p,dir)
- self.assertEqual(p,o.project)
- self.assertEqual(dir,o.directory)
- self.assertEqual(OUTPUT_ID_HOME,o.id)
- self.assertRaises(AssertionError,Homedir,None,dir)
- self.assertRaises(AssertionError,Homedir,"someproject",dir)
- self.assertRaises(AssertionError,Homedir,p,None)
- self.assertRaises(AssertionError,Homedir,p,p)
+ self.assertRaises(AssertionError,Output,"someproject")
def test_jar(self):
wname = "blah"
Re: svn commit: r170842 - in /gump/branches/Gump3
Posted by Leo Simons <ma...@leosimons.com>.
On 26-05-2005 16:39, "Adam R. B. Jack" <aj...@apache.org> wrote:
>>> 1) Removed Homedir, since <home> isn't an output.
>>
>> Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of
> native
>> 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.
Yes please. Those docs are just confusing as hell. Please do take the lead
here, you have more experience with the actual needs than I do :-)
>>> 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.
I strongly disagree here. A simple test that fails is usually, at a minimum,
a test that can be "inverted" to test failure condititions.
Passing a string for a project was a bad idea. Having a test for it was a
good idea. Changing the code to not accept a string for a project is a good
idea. Removing the test is a bad idea. Add a test that ensures failure if
you pass a string for the project.
Testing simple things is simple. Testing hard things is hard. We should work
hard to make the hard things simple enough to be able to test them. That
probably means DynaGumper needs to change a lot more so you can make the
tests work.
> 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 thought about that, and I don't think we should be doing that. If you have
small partial mock models (just enough to run a particular test), it helps
you ensure that your code is loosely coupled.
> Also, I want to do small/incremental commits, so we can view as we go.
+1
> If that sometimes breaks unit tests, and forces a discussion, thatis fine by
> me.
I've got some reservations, but I suggest we don't discuss this much
further. Every developer on the planet has a different opinion on how to be
a developer. We'll see where we go :-)
>> That's just ugly, right?
>
> Do I have to mark #UGLY to let you know I know? ;-)
No, you need to let your mind soar and think of the beautiful alternative. I
know you've thought about it (I read 4 years of gump e-mail the other day
:-)), I just want to get you to live up to your own ideals. Aim high!
> And to me. Please do read [1] below, as it might explain how it came into
> existence.
I will.
>> 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
> you're
>> 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.
Even in hindsight, the decision you made in "perpetuating not improving"
with gump2 was the right decision and we all knew that then and there. I
still know it. You have no right to blame yourself!
> 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.
Exactly.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r170842 - in /gump/branches/Gump3
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> > 1) Removed Homedir, since <home> isn't an output.
>
> Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of
native
> 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
me.
> > Modified: gump/branches/Gump3/pygump/python/gump/engine/objectifier.py
> ...
> > 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
to
> 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
up
> 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
because
> 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/__init__.py
> ...
> > + - 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
existence.
> ...
> > +class WorkItem(ModelObject):
> > + """Model a directory containing stuff that can be used by other
projects.
> ...
>
> If its used by other projects then its an Output.
>
> > Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py
> ...
> > + # Any internal build artifacts
> > + for work in project.workitems:
> > + self.classpath +=
> > ArtifactPath(work.name,output.path.resolve(self.workdir))
>
> It really is a mess. We need to get rid of <work/>, <home/>, etc. What
would
> 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
accordingly.
> Or actually, we could probably extract the logic bits (and xml
definitions)
> that work well from the way ant does all this, ie
> http://ant.apache.org/manual/using.html#path.
>
> 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
you're
> 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.
regards,
Adam
[1] http://gump.apache.org/metadata/project.html#home
[2] http://gump.apache.org/metadata/builder.html#property%2Farg
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: svn commit: r170842 - in /gump/branches/Gump3
Posted by Leo Simons <ma...@leosimons.com>.
On 19-05-2005 01:26, "ajack@apache.org" <aj...@apache.org> wrote:
> Author: ajack
> Date: Wed May 18 16:26:26 2005
> New Revision: 170842
>
> URL: http://svn.apache.org/viewcvs?rev=170842&view=rev
> Log:
> 1) Removed Homedir, since <home> isn't an output.
Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of native
code projects find each other via a "prefix" directory. Step out of the
confines of the java world :-)
> 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 :-)
> Modified: gump/branches/Gump3/pygump/python/gump/engine/objectifier.py
...
> 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 to
automate "clean up imports".
> +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 up
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?
> + # Work Items
> + works = project_definition.getElementsByTagName("work")
> + for work in works:
Similarly, <work/> is harmful and should be superfluous (we have it because
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).
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/__init__.py
...
> + - homedir -- None or a ResolvablePath (outputs are relative to
> this)
See how confusing that is? At least it is to me!
...
> +class WorkItem(ModelObject):
> + """Model a directory containing stuff that can be used by other projects.
...
If its used by other projects then its an Output.
> Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py
...
> + # Any internal build artifacts
> + for work in project.workitems:
> + self.classpath +=
> ArtifactPath(work.name,output.path.resolve(self.workdir))
It really is a mess. We need to get rid of <work/>, <home/>, etc. What would
make sense is something like
<repository name="ant">
<module name="ant">
<project name="ant">
<ant>
<classpath>
<directory="build/classes">
</classpath>
</ant>
</project>
</module>
</repository>
Or actually, we could probably extract the logic bits (and xml definitions)
that work well from the way ant does all this, ie
http://ant.apache.org/manual/using.html#path.
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 you're
magically transforming xml into a bash script, but otherwise...
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org