Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
From: "Stephen McConnell \(DPML\)" <mcconnell@apache.org>
To: "'Ant Users List'" <user@ant.apache.org>
Subject: RE: Re: Maven vs. Ant?
Date: Fri, 16 Jun 2006 15:10:21 +0930
Message-ID: <001501c69107$5c8c8770$0201a8c0@julia>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcaOVpEjXeHWR6KCSL+1sUAvHm3JgACL98sg
In-Reply-To: <20060612192916.240730@gmx.net>

 

> -----Original Message-----
> From: Antoine Levy-Lambert [mailto:antoine@gmx.de] 

> 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: 

    Transit is a resource management system that lets you work with 
    uri instead of urls - where uris include
artifact:[group]/[name]#[version]
    (for cached based retrieval of versioned resources backed by local
and/or
    remote repositories), link:[group]/[name]#[version] which provides
something
    similar to a symlink, and local:[group]/[name]#[version] for retrieval
of 
    local preferences.  Above the resource management layer is a plugin 
    management system that combines 'deployment data' and 'classloader
chain' 
    information into XML files that can be used by the system to
automatically
    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>
declarations.
    Modules identify a namespace for a group of resource and/or projects.
Projects
    identify a working base directory. Projects can declare scoped
dependencies 
    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
(which
    may be direct name/token substitution or feature based substitution -
e.g.
    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
library
    to resolve project base directories, transitive dependencies,
properties, 
    and filters.  It uses the Transit system for all resource management
concerns 
    including support within Transit for the declaration and deployment of
plugins
    (where a plugin is somewhat equivalent to an antlib plus classloader 
    definition).  Depot uses Transit for loading build templates and
antlibs.  
    Depot also includes a small number of Ant tasks that enable build
automation
    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.).
When
    the generic Depot tasks don't meet all of our needs - we simply add
extra 
    stuff into build.xml files (i.e. its just driving classic Ant).

  Metro:

    Metro is an alternative plugin strategy.  In effect Transit plugin
definitions
    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
out-scope
    here but generally makes for very easy development.  The Metro platform
also
    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
usage).

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
     project.

     $ cd <dir>
     $ build -list

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

       version: SNAPSHOT
       basedir: C:\dev\dpml\main\metro\state\impl
       types: (1)
         jar
       runtime providers: (2)
         project:dpml/metro/dpml-state-api#SNAPSHOT
         resource:dpml/transit/dpml-transit-main#SNAPSHOT
       test providers: (6)
         resource:ant/ant-launcher#1.6.5
         resource:ant/ant-trax#1.6.5
         resource:ant/ant-xslp#1.6.5
         resource:ant/ant#1.6.5
         resource:junit/junit#3.8.1
         resource:ant/ant-junit#1.6.5

  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 
     like:

     $ 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 
     'install'.

     $ 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
mailto:mcconnell@dpml.net
http://www.dpml.net
 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org