gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: heresy - a controversial or unorthodox opinion or doctrine
Date Sun, 11 Jul 2004 05:46:50 GMT
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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message