Questions about Depot
mcconnell at dpml.net
Mon Feb 27 20:59:00 EST 2006
> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of David Leangen
> Sent: Tuesday, 28 February 2006 12:20 AM
> To: DPML Dev
> Subject: Questions about Depot
> Hi, Steve,
> I've been looking at Depot tutorial. It seems very nice.
> Do the concepts of templates and plugins still exist? It
> would be nice to be able to provide extensions, when necessary.
For info about template selection:
Concerning plugins ...
There are several examples of build-time plugin usage in the codebase. For
example the following Depot <plugin> task loads a custom plugin that does
the work of component definition creation (which is totally unknown to
Once the plugin is loaded you can directly reference it using the 'urn'
argument as the 'xmlns' value.
For example the <component> element is identified as a task defining in the
link:plugin:dpml/metro/dpml-metro-tools plugin by virtue of the 'xmlns'
(the xmlns="metro" resolves to the "link:plugin:dpml/metro/dpml-metro-tools"
urn and 'component' is resolved relative to the plugins antlib definition.
<component xmlns="metro" type="net.dpml.http.Server"
This provides a fully extendable environment however it also presumes that
build-time plugins are declared as Transit plugins (a restriction that I
to remove before release.
> And what about multiple projects and/or index files? Is this
> possible, or does everything now need to be in one library.xml file?
The library.xml is located by searching from the current directory up the
directory hierarchy until a library.xml file is located. This allows the
possibility for lots of different library definitions, and the possibility
for a library to override a higher-level library (for example the external
module package in DPML has its own library which exists at a deeper level
from the main DPML library.
More information about the dev-dpml