Ted:
> 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.
I envisioned the Wiring tool as just being responsible for the specification of
how an Outpost application was wired together (which embedlets, device
drivers/JAPLs, adapters), and would simply generate the XML Config file
declaration that represents this wiring. Then it would only call the regular
(non-graphical) build process upon request (which might be an ANT build, but
that is just calling a java process like almost any other).
The actual code generation (if needed), compiles and packaging would be
done by the build process, not the Wiring tool. There is good reason to keep
the build process decoupled from the wiring process in this way.
As for deployment, that will almost always be application specific, as in your
multiple controller/PDA/etc. example. It gets more complicated since some of
our target platforms will not easily support dynamic reconfig/redeployment
(think about a JStamp....you need a JTag connection to load/burn new code).
I think that application-specific deployment will not be something that we
should/can tackle early on (if ever) in the Embedlets project. Admittedly, the
deployer (put your high-paid consultant hat on, Ted! ;-) ), could probably
create automated deployment capabilities using Ant, but they would be custom
to each implementation.
Brill adds:
> I assume the application does not need Ant to work.
That is correct....the runtime will not require Ant, just the
build/assembly/packaging process.
> 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 intention is that both the Container (Outpost) and Component (embedlet)
XML config files will NOT be Ant format. They will be more akin to the Tomcat
server.xml and servlet web.xml files. The Ant build.xml file would be a
separate file, and would/could use the config files in the various stages of the
build as appropriate (eg. for code generation of static application "glue/wiring"
logic for very constrainted platforms). What this means is that the build
process can be automated with Ant, but all the "ingredients" that specify the
final Outpost app could be built with a different tool using the individual
container config, component configs, wiring specification, classes, etc.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
