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)
Message-ID: <44927DF8.6060402@apache.org>
Date: Fri, 16 Jun 2006 10:46:32 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Ant Users List <user@ant.apache.org>
Subject: Re: Maven vs. Ant?
References: <001501c69107$5c8c8770$0201a8c0@julia>
In-Reply-To: <001501c69107$5c8c8770$0201a8c0@julia>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephen McConnell (DPML) wrote:
>  
> 
>> -----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.  
> 

wow, that was a very thorough investigation, thank you. I will add a 
pointer to DPML in the library management chapter of Java-Dev-with-Ant, 
which is pretty much focused on the m2 tasks, for better or worse.

Are you building as part of gump?

Trying to get library management and gump to work together is pretty 
problematic, as essentially ant-under-gump ignores any classpaths you 
set up for compiling, the gump descriptors predefine everything. The 
library management tasks need to go through the steps of appearing to 
work, without setting up any classpaths. all other aspects of their 
process (e.g. publishing) should still be supported.

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


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