Hello Stephen, thanks for your explanations.
I need to build up my culture and understand how other tools or frameworks related to build position themselves in comparison with ant. So DPML delegates build tasks to ant. Maven2 tries to replace ant completely by providing similar functionality (for instance wrapping around javac and jar). Interesting to see that there is some overlap - and so maybe some duplication of efforts - between different open source projects. I wish I had the time to study fully both DPML and Maven. Right now, I am studying Maven. Regards, Antoine -------- Original-Nachricht -------- Datum: Fri, 16 Jun 2006 15:10:21 +0930 Von: "Stephen McConnell (DPML)" <[EMAIL PROTECTED]> An: \'Ant Users List\' <user@ant.apache.org> Betreff: RE: Re: Maven vs. Ant? > > > > -----Original Message----- > > From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > http://www.dpml.net > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
