[MAGIC] issue concerning multiple outputs
Stephen McConnell
mcconnell at dpml.net
Sun Jan 30 11:01:45 EST 2005
> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of
> Niclas Hedhman
<snip>
> For instance, I would like to see the disappearance of the
> <x:block> in build.xml, as it makes it more difficult for
> other tools to figure out what is going on, whereas a "block"
> process would require the block definition in a separate
> file, upon which the BlockTask would do its magic. Agreeably
> a simple copy-with-filter won't cut it, and some serious
> thought process is probably needed in this particular area.
I agree.
> But I think some form of "process" concept would be good, and
> each process produces a single output artifact. (whether it
> must be the same group or not is less relevant at this stage).
I've thinking along the lines of :
* <resource> as the definition of a set of typed artifacts
under a single group, name and version
* <project> the definition of the location of the sources
for a given <resource> and the declaration of possibly
multiple <process> declaration
* <process> associates a <project> with n input resources and
a single <processor>
* <processor> definition of a type of process - it declares
the allowable input resource types, an implementation
plugin, and a single output type
So for example we declare somewhere (site wide) the available processor
types. Note that the following definition does not declare the processor
plugin - its just the definition of a processor type. The association of
plugins with processors would be a part of the system configuration.
<processor urn="processor:dpml/magic/dpml-magic-jar" name="jar">
<properties>
<property name="project.jar.index" default="true"/>
<property name="project.jar.compress" default="true"/>
</properties>
<inputs>
<input type="dir" name="etc" default="${project.etc}/main"/>
<input type="dir" name="main" default="${project.src}/main"/>
<input type="path" name="classpath"
default="${resource.runtime.path}"/>
</inputs>
<outputs>
<output type="jar" name="jar"/>
</outputs>
</processor>
You can think of the above as the meta-info about a process type. If we
look at a process (the meta-data declaration) we could imagine something
like the following:
<project key="widget">
<info>
<group>acme</group>
<name>acme-widget</name>
</info>
<dependencies>
<dependency key="gizmo"/>
</dependencies>
<processes>
<process name="jar"/>
<process name="plugin" depends="jar"/>
</processes>
</project>
>From the above information we have everything necessary to build two output
artifact acme-wiget.jar and acme-widget.plugin. First off all, no build file
needed. Instead we ...
* read in the definition from an index
* resolve the processor execution sequence relative to the 'depends'
attributes
* lookup the processor using the name attribute (or optionally
via a urn attribute - name is just for convenience)
* the processor declares all of the default, e.g. the src directory,
recognized properties, the classpath path id, etc.
* before instantiating a process we can valid that the definition
is rational in structural terms
* for each processor in the sequence, we lookup a plugin assigned to
the processor type (system config) instantiate it, and execute it
* and for user's who need to do special stuff, we provide an ant
processor that can be squirted in anywhere .. E.g.
<processes>
<process name="jar"/>
<process name="plugin" depends="jar"/>
<process name="ant" depends="plugin">
<basedir dir="widget"/>
</process>
</processes>
> TIWIT (that is what I think) :o)
AWDYTOT?
(And What Do You Think Of That ?)
Cheers, Steve.
> Niclas
> _______________________________________________
> dev-dpml mailing list
> dev-dpml at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/dev-dpml
>
More information about the dev-dpml
mailing list