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]
