[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