> -----Original Message-----
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Sent: Friday, 16 June 2006 7:17 PM
> To: Ant Users List
> Subject: Re: Maven vs. Ant?
>
> Stephen McConnell (DPML) wrote:
> >
> >
> >> -----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.
> >
>
> 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.
I can provide pointers to additional info if needed.
>
> Are you building as part of gump?
Not at this time (no technical reason why not - just a question of
resources).
>
> 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.
I've been through the process of developing a builder for gump and handling
all of the 'special' stuff related to Ant classloader manipulation. Based on
that experience combined with the Depot background I've developed some
'strong' opinions concerning Gump and the general continuous integration
subject. As concerns the Depot Build Tool - the repository configuration is
declared within the Transit system (a XML file detailing the repositories
that are accessible to the build system and runtime applications) - as such
it would be easy to configure Transit to work exclusively from a local
repository that is populated by Gump-driven builds (an example of a classic
company intranet config).
Where things get a little sticky is when you look at the subject of build
control where the following two possible scenarios emerge:
(a) gump is in command and the Gump descriptor is the authorative source
(b) the build tool is in control and the build systems descriptor is the
authorative source
I am very much in the B camp. The assumption that the trunk/head of any
given project should be resolvable relative to all other projects handled by
Gump is an assumption I don't think is scalable due to conflicting
priorities. To make this point more succinct - I (average developer) may be
interested in building against Ant HEAD but I don't want any project
building against anything from me other that a DPML n.X (where n is a
published final version). Also, I want to exclude noise - for example - I'm
not interested in building my system against version SNAPSHOT of the Jasper
Runtime - I just want to lock down on the 5.5.15 distribution (I.e. I
want/need to focus/prioritize the level of community integration that is
relevant to my project).
The inverse of this position is the Tomcat project and the interest they
have in building something like the DPML using Jasper HEAD (or the Ant
project building DPML and observing the impact of changes to HEAD or a
consumer such as the DPML).
These are two competing views:
(a) a project centric view of dependencies
- I (project) depend on X, Y, and Z (projects)
and I want a continuous integration tool to
track the impact of their changes on my codebase
(b) and, the project centric view of consumers
- I (project) have implemented changes and I want
a continuous integration tool to flag potentially
negative consequences of those changes on
downstream projects
Resolving the above two concerns requires two distinct gump descriptors. If
I take the DPML as an example then my main external HEAD dependencies that
I'm interested in tracking are Ant and Jetty. There are a bunch of
secondary dependencies that I do not want to monitor (commons-el, slf4j,
java2html, commons-collections, commons-logging, checkstyle, etc.) because I
have locked down on a specific binary distribution. My second descriptor is
the descriptor I provide for client - in effect I want clients to link
against DPML 1.0.0 and I want issues raises to reflect issues relative to
anything in 1.0.0. I also want to be able to run silent (sneaky) builds of
consumer projects using DPML 1.0.1-SPECIAL-XYZ-VERSION against all consumers
of DPML 1.X and get notification of failures back to me and me only. I.e.
my exploration (refactoring or whatever) should be a process (a.k.a.
overhead) that I deal with and should not impact my consumers (a.k.a
customers).
Achieving he above would require a project centric continuous integration
process and this is a subject of interest with respect to Depot development.
We currently have the ability to export a library definition into a
exportable module definition - but this focussed on runtime requirements.
What is missing is the publication of the original library source from which
a process can automatically build a project or projects from source (plus a
nice manipulation config file to enable build of project X using results of
Y/HEAD for declared dependency on Y).
Cheers, Steve.
> > 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]
