> One reason is because using Ant or not makes a significant impact on how
the
> Wiring Tool is designed. If we make the decision to go with Ant then I
can see
> how the Wiring Tool could heavily leverage Ant's capabilities for
everything
> from application assembly to packaging and deployment. It would be much
easier
> to start laying out the architecture of the Wiring Tool if this decision
were
> made up front.
Why would it matter to the wiring tool if you used Ant in the dev.
environment?
I assume the application does not need Ant to work.
If you want to use XML for the wiring "file format" you might try the
built-in registry stuff in JDK1.4.. its fairly good, and you can export the
XML... I've actually already used it that way to create a standard "file
format" for another application.
Anyway, using Ant would work and might provide a good tool for those who
want to use a command-line system... however I don't think the XML file
format *has* to be the Ant format... in fact I could think of some arguments
against it (also for it but thats another thing) starting with separation of
usage (which I think is a good idea in this case).
> The Wiring Tool is one reason to make this decision now and here is
another.
> After studying how Ant is leveraged in the Architecture document, it is
> becoming increasingly obvious to me that without something like Ant that
> Embedlets can not reach their full potential.
Embedlets should not depend on Ant... though tools may be written for Ant to
access the Embled implementation (Outpost). IMO.
- Brill Pappin
|
