[Gump Wiki] New: GumpDevelopment/Changes
Date: 2004-07-19T14:51:30 Editor: AdamJack [EMAIL PROTECTED] Wiki: Gump Wiki Page: GumpDevelopment/Changes URL: http://wiki.apache.org/gump/GumpDevelopment/Changes no comment New Page: = GumpDevelopment/Changes = * Much of working with the GumpCode requires the changes to /MetadataProcessing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] New: GumpDevelopment/Changes/MetadataProcessing
Date: 2004-07-19T15:07:18
Editor: AdamJack [EMAIL PROTECTED]
Wiki: Gump Wiki
Page: GumpDevelopment/Changes/MetadataProcessing
URL: http://wiki.apache.org/gump/GumpDevelopment/Changes/MetadataProcessing
no comment
New Page:
= GumpDevelopment/Changes/MetadataProcessing =
There are two aspects to working with metadata in Gump.
* Loading Metadata (from a local repository and/or from remote URLs)
* 'Completeing' metadata to Objects.
== Loading Metadata ==
Metadata is loaded using tasks (not yet multithreaded) that fetch the data, parse the
XML into a DOM, and then 'resolve' (for want of a better word) the XML into
ModelObjects (e.g. Workspace/Profile/Module/Project, etc.)
Attempts are made to resolve URL links to metadata using the 'base' of the current XML
document. Attempts are made to resolve object for the DOM metadata using the parent
object to determine what those might be.
Basically the workspace and profile becme objects that create module and/or project
objects for all module and project elements (they also weave them into a workspace
tree of objects).
== Completing Metadata ==
Once loaded the objects are request to 'complete themselves', which involves resolving
variables (like @[[Date(2004-07-19T22:07:18Z)]]@) and includes creating sub-objects
for things like jars and work, etc.
Another aspect of 'completion' is to wire all the pieces togeter, so the model objects
are fully usable at the higher level. Once 'complete' there ought be the correct
memory maps for project inter-dependencies, and so forth.
= Making Changes =
Adding new capabilities (or changing existing) to this area typically means working on
the content of the {{{gump.model}}} modules, and adding unit tests to
{{{gump/test/model.py}}} (after adding XML to {{{gump/test/resources}}}).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] New: GumpDevelopment
Date: 2004-03-03T13:39:58
Editor: AdamJack [EMAIL PROTECTED]
Wiki: Gump Wiki
Page: GumpDevelopment
URL: http://wiki.apache.org/gump/GumpDevelopment
First whack
New Page:
= Gump Development =
Gump development is primarily in Python, see GumpPython.
Gump use Python 2.2, not 2.3, which means a set of features are not available.
= Debugging =
Gump uses the standard Python 'logging' package (bundled in 2.3) but has a copy of it
[under python/] for 2.2. Typically the command line options of ''--debug'' and
''--verbose'' turn this on. Gump code current uses a single log instance (not one per
package/module).
Write to the log using log.debug( )
A very useful feature in exception cases is the following, the exc_info=1 (there is no
True in Pythong 2.2) logs a stack trace. The details object is often informative also.
try:
...
except Exception, details:
log.error('Problems problems...' + str(details), \
exc_info=1)
= Testing =
Unit tests (not yet converted to the real pyunit, a knock off but similar) are run
using:
python gump/test/pyunit.py
One can run a single test (or set of tests) by passing a wildcarded (filename-like not
regexp) expression. e.g. *Nag for all nag tests. This matches the method (test) name,
not test suite name.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
