ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell \(DPML\)" <>
Subject RE: Re: Maven vs. Ant?
Date Fri, 16 Jun 2006 05:40:21 GMT

> -----Original Message-----
> From: Antoine Levy-Lambert [] 

> And what about dpml ?

I guess first off is the statement that the DPML content is not aimed at or
equivalent to Maven.  Generally speaking the DPML products are focussed on
runtime requirements with the single exception being the Depot build tool.  

To put things into perspective - DPML includes:


    Transit is a resource management system that lets you work with 
    uri instead of urls - where uris include
    (for cached based retrieval of versioned resources backed by local
    remote repositories), link:[group]/[name]#[version] which provides
    similar to a symlink, and local:[group]/[name]#[version] for retrieval
    local preferences.  Above the resource management layer is a plugin 
    management system that combines 'deployment data' and 'classloader
    information into XML files that can be used by the system to
    deploy complex systems. 

  Depot Library: 

    The library provides a framework for the <resource> declarations (e.g. 
    jar file, XML files, etc.), <project> declarations, and <module>
    Modules identify a namespace for a group of resource and/or projects.
    identify a working base directory. Projects can declare scoped
    covering BUILD, TEST and RUNTIME phases.  Runtime phases can be further 
    qualified to separate PUBLIC, PROTECTED and PRIVATE scopes.  In addition
    project definitions may include property and filter declarations and
    may be direct name/token substitution or feature based substitution -
    lookup the version of project X and replace token Y with the value).

  Depot Build System:

    The build system is composed of a command line handler that uses the
    to resolve project base directories, transitive dependencies,
    and filters.  It uses the Transit system for all resource management
    including support within Transit for the declaration and deployment of
    (where a plugin is somewhat equivalent to an antlib plus classloader 
    definition).  Depot uses Transit for loading build templates and
    Depot also includes a small number of Ant tasks that enable build
    of the majority of the DPML project.  Generally speaking these ant tasks
    are simply pulling in info from the library (e.g. compile path creation,

    test path creation, meta-data creation, property resolution, etc.).
    the generic Depot tasks don't meet all of our needs - we simply add
    stuff into build.xml files (i.e. its just driving classic Ant).


    Metro is an alternative plugin strategy.  In effect Transit plugin
    allow for the declaration of alternative object deployment strategies.
While the 
    basic Transit plugin model supports a simple generic framework
(including antlib
    resources loading) - the Metro system goes a lot further and provides 
    support for composite objects, lifecycle management, custom lifestyle, 
    Context-IOC, remote management, logging, and bunch other stuff that's
    here but generally makes for very easy development.  The Metro platform
    includes a the 'Station' - in effect a server handles multiple JVMs and 
    provides support for remote application management.

>From the above - the things loosely comparable to Maven include the Transit
resource management layer (in terms of repository-based resource
functionality), the Depot library (in terms of full transitive dependency
management) and the Depot Build System (in terms of multi-project build
automation).  Each of these areas are distinct but dependent. Depot is the
tool we depend upon to create precise metadata for plugins (leveraging
transitive scoped runtime dependencies).  This metadata is used by Transit
to deploy plugins under classloader chains that make sense at runtime.  The
metadata can include references to other plugins that handle custom
deployment solutions (e.g. Metro as an example of a custom deployment
strategy) and classloader chains are declared in terms of Transit artifacts
(which guarantees version integrity and runtime support for repository

I guess the major difference is that the DPML products are very dependent on
the runtime integrity of transitive dependency information.  Maven did not
provide the level of integrity we needed (and combined with frequent
technical issues related to Maven usage) which prompted the development of
solutions specifically focussed on our runtime priorities.

Some practical features:

  1. References to properties and filters that are features of 
     a project are subject to build-time validation - thereby 
     reducing significantly the possibility of errors in property 
     name references.

  2. Project, resource and module definitions are all subject 
     to XML schema validation (which also means you can include 
     custom schema and extend the respective definitions).

  3. Compile and test path creation is automatic and takes into
     account the full transitive dependencies relative to runtime
     or test scope.

  4. Usage of Depot Ant Tasks is optional but when used assumes
     a formal project structure (which can be customized - e.g.
     doing a build Jetty (which has a Maven structure) is performed
     locally on my machine using Depot (and executes without any
     unexpected downloads).

  5. The build tools is build system independent - in effect it 
     just launches and executes a plugin - the default plugin is 
     the Depot Build System which is basically an application that
     creates a new Ant Project, adds a ComponentHelper, assigns 
     a project context (the link to the library) and pulls in 
     a build template (the actual plugin can be customized at the 
     system level and individual projects can override the template
     or specify a build file directly).

  6. The build tool provides convenient access to project 
     summaries - for example, the following command lists 
     info about the DPML State Machine Implementation

     $ cd <dir>
     $ build -list

       Listing project: dpml/metro/dpml-state-impl

       version: SNAPSHOT
       basedir: C:\dev\dpml\main\metro\state\impl
       types: (1)
       runtime providers: (2)
       test providers: (6)

  7. The build tool provides support for multi-project builds
     by consulting the library and resolving the ordered sequence 
     of projects relative to the current working directory
     (handy when working with large numbers of projects). E.g.
     The following command requests the listing of all projects
     with a basedir or below the current working directory.  The
     listing is sorted relative to project dependencies.

     $ cd ..\..
     $ build -list

     [1]   project:dpml/metro/dpml-state-api#SNAPSHOT
     [2]   project:dpml/metro/dpml-state-impl#SNAPSHOT
     [3]   project:dpml/metro/dpml-job-api#SNAPSHOT
     [4]   project:dpml/metro/dpml-metro-component#SNAPSHOT
     [5]   project:dpml/metro/dpml-metro-model#SNAPSHOT
     [6]   project:dpml/metro/dpml-job-impl#SNAPSHOT
     [7]   project:dpml/metro/dpml-metro-runtime#SNAPSHOT
     [8]   project:dpml/metro/dpml-metro-tools#SNAPSHOT
     [9]   project:dpml/metro/dpml-metro-test#SNAPSHOT
     [10]  module:dpml/metro

  8. The build tool also provides support for the building 
     consumers of a specific project - for example if I've just 
     changed project X, and I want to rebuild all projects
     impacted by a modification to X (taking into account 
     full transitive consumer resolution), I can do something 

     $ cd state\api
     $ build -consumers
     [1]   project:dpml/metro/dpml-state-impl#SNAPSHOT
     [2]   project:dpml/metro/dpml-metro-component#SNAPSHOT
     [3]   project:dpml/metro/dpml-metro-model#SNAPSHOT
     [4]   project:dpml/metro/dpml-metro-runtime#SNAPSHOT
     [5]   project:dpml/metro/dpml-metro-tools#SNAPSHOT
     [6]   project:dpml/metro/dpml-metro-test#SNAPSHOT
     [7]   module:dpml/metro
     [8]   project:dpml/planet/http/dpml-http-impl#SNAPSHOT
     [9]   project:dpml/planet/http/dpml-http-server#SNAPSHOT
     [10]  project:dpml/planet/http/dpml-http-test#SNAPSHOT
     [11]  module:dpml/planet/http
     [12]  module:dpml/planet
     [13]  project:dpml/station/dpml-station-api#SNAPSHOT
     [14]  project:dpml/station/dpml-station-builder#SNAPSHOT
     [15]  project:dpml/station/dpml-station-server#SNAPSHOT
     [16]  project:dpml/station/dpml-station-exec#SNAPSHOT
     [17]  project:dpml/station/dpml-station-console#SNAPSHOT
     [18]  module:dpml/station
     [19]  module:dpml

  9. The build tool can also by used to apply multiple build 
     targets to a selection of projects.  For example, the following
     command line invokes a ant builder with the target 'clean' and 

     $ build clean install

     If there are multiple projects relative to my current 
     base-directory then the clean and install targets are invoked
     on all of the projects matching the selection.

  8. But the most important function of the build tool in part meta 
     data generation (which requires absolute precision concerning 
     transitive dependency resolution).  It's in this area that we 
     can move gracefully from definitions of inter-dependencies
     (via the library) through build-time execution (using the depot 
     builder), the generation of correct runtime data (a specialized 
     depot Ant Task), to reliable runtime hot-deployment of sub-systems
     (via Metro and the Station).

We are still working though documentation. All of the reference content is
complete but the tutorials are taking time.  In actuality I would say that
the tutorials are the biggest and most significant impact - you go to write
the details of how it should work and your put in place an example - and
when the example does not run as expected you are forced to go back and sort
out the issue. In principal we should have discovered these issue in
test-cases - but we already have over 1000 testcases in place and there are
still issues emerging from the tutorials.  Anyway - we are up to RC9, a RC10
will be coming in a few days and a 1.0 is not far away.

Cheers, Steve.

Stephen McConnell

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message