Adam R. B. Jack wrote:
Well - maybe its not that bad ... but all the same - this is an early warning .. I'm thinking about making a copy of AntBuilder (gump/python/gump/builder/ant.py), renaming it to magic.py, making a couple of small but significant changes, sorting out what actually does the builder selection, updating it submitting a patch. And all of this with zero Python experience and no compiler.
Nothing slightly heretic (unless you are talking about Ant religion not Gump religion). Magic is like Ant (based upon, I believe) but different, so you approach seems totally correct given today's Gump codebase. The only (small but significant) extras I can think off would be:
1) Add a <magic element to the project metadata (like <ant, like <maven) and update gump/model/builder.py to have such a Magic class (based upon Builder), just like the Ant class. [Feel free to update xdocs for site documentation.]
2) Modify gump/model/project.py to create the self.magic member data, and hasMagic(), getMagic() beaner methods, and clone that small section in complete() (that constructs objects from XML) that constructs a Magic class for a <magic DOM element.
3) Update gump/build/builder to have a self.magic and then if project.hasMagic() to call your gump/builder/magic.py.
If this sounds like heresy then please yell out now because as I see it this is the next step in moving the magic gump equation forward. If anyone wants to shepherd me though the process I'll be very grateful.
We have ant.py and maven.py, so when not magic.py? Get a few more and we can refactor these steps about to allow (1) auto-discovered/auto-loaded plugins based upon the element name (2) element name to model/builder auto mappings. A few more and we'll have enough experience for a reasonable plug-in strategy. (For example, I think the CLASSPATH generation could move into the builder, so we could have similar but non-Java such stuff).
BTW: What are the differences between Ant and Magic as far as Gump is concerned?
A MagicBuilder would set specific system properties (gump date, probably a verbose flag, exclusion of build.sysclasspath) and modify the classpath to be ant, junit and magic. Secondly, the semantics of gump <depend> would be interpreted as a <depend><noclasspath>.
But in digging around I think this is step one of a two step process. In effect a MagicBuilder really only reduces the number of lines of gump information that needs to be read in - the real kicker will come from a magic module and the interaction between a magic module and a magic builder - but this is pure thinking ahead and I'm still dealing with the fact that someone has removed all of the braces from the source code!
:-)
Cheers, Steve.
regards
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
