[ANNOUNCEMENT] DPML SDK 2.0.0 major update
mcconnell at dpml.net
Mon Apr 16 17:10:34 EDT 2007
The DPML SDK 2.0.0 (major update) is available.
Version 2.0.0 is the latest production stable build of the DPML platform. It
incorporates a number of important functional enhancements over the 1.X
series brought about through an internal restructuring of the component
deployment architecture. The 2.0.0 version has a structural dependency on
the Java 1.6 platform. Semantics of component deployment such as Context
definition remain backward compatible with the 1.X series. Internal APIs
have changed relative to 1.X to better align with draft JSR 277 module and
294 Modularity specifications.
New features and/or enhancements delivered under version 2.0.0 relative to
* JSR 277 readiness.
* Integral support for java.util.ServiceLoader as an basic extension
* Support for plugable content type handlers via java.util.ServiceLoader.
* JMX management of the Transit resource management layer.
* Metro component model moved to a dedicated content type handler.
* Support for nested contect interface defintions.
* Context model suport for map datatypes.
* Support for uri fragment argument handling.
* Improved part interface semantics.
* Improved XSD namespace management.
* Package namespace updates to facilitate improved private class isolation.
* Comprehansive updates to tutorials and online documentation.
* Improvements to Station deployment metadata.
This version is to some extent 'raw' in that it is not so friendly if your
planning on migrating from 1.X. Improvements related to migration are
currently being address under the Trank version (principally improvements to
error handling when building 1.X based code with version 2). These updates
will appear in a 2.0.1 release which should be available within a few days.
1. Changes to the Depot index schema and namespace.
1.1 Namespace changes
The XML namespace for index files, imported module and imported project
files has changed from "link:xsd:dpml/lang/dpml-lang#1.0" to the new
namespace "dpml:library". This change has been
brought about a simpler architecture for new namespace resolution. Instead
of the namespace
serving as an implicit resource identifier, version 2.0.0 leverages the
to load a schema validator for any unknown schema references.
1.2 Schema Changes
The schema definition has been simplified with the removal of inline
declaration of product
type data structures. For example, under version 1.1 you could define a
project using the
following in-line component type declaration:
<project name="foo" basedir="foo">
<part:plugin class="org.acme.Foo" alias="true"/>
In the above XML sample the declaration of '<part:plugin .../>' is an
example of an inline
declaration. Under version 2.0.0 the equivalent definition is handled by a
production statement using the new 'source' attribute referencing an XML
part deployment strategy.
<project name="foo" basedir="foo">
<type id="part" alias="true" source="component.xml"/>
2. Part data type management changes
2.1 Separation of part schema from strategy schemas.
The schema definition for the 'part' data type has been updated such that it
no longer defines any concrete deployment strategies (version 1.1 include
resource and plugin definitions). Instead, resource declarations may
defined under an XML file with a root <resource> element with the namespace
"dpml:antlib". Plugin definitions have been removed as these are now
redundant in that all plugin functionality is fully supported by a
<component> definition under the "dpml:metro" namespace. Under this revised
structure the introduction of new schemas is much simpler because new
alternative strategy schemas can be loaded dynamically, as are handlers for
the strategy type.
3. Metro component strategy
3.1 Component annotations
Version 1 provided support for the declaration of component meta-data via a
collocated .type data file. This concept has been replaced under version
2.0 with class annotations that provide for the declaration of component
features and policies. This change eliminates a substantial area of code
dealing with component type data structure generation.
3.2 Enhancements to the <context> definition
The <context> nested element can now include nested context entries, and
entries that resolve to map-based structures. The nested context support is
of particular interest when dealing with 'standard' context interfaces
declared as return types within an enclosing context interface. In
addition, Metro 2.0.0 includes a Context annotation enabling the declaration
of an interface as a context definition - enabling the use of alternative
interface names and improving overall flexibility in context contract
specification and use.
3.3 Bundled deployment defaults
A deployment profile can be collocated with a class file under the name
<classname>.xprofile. The deployment profile contains the declaration of the
default context and any other component data to be applied on the
establishment of a component model before subsequent customization based on
a component directive within a part data structure. In addition, component
policy (such as lifecycle, lifestyle, etc.) can also be associated with a
component class via respective annotations. Collectively these enhancement
eliminate the need for the metro component ant task (which in turn
eliminates a significant amount of code and provides a marked performance
improvement related to component loading and deployment).
4. Embedded Component Deployment Enhancements
4.1 Content Handlers abstraction
Introduction of artifact content handlers into the Transit resource
management layer has enabled the separation of all 'part' content handling
to an external system. In the case of the 'part' content hander a part
definition is analysed and a strategy element loaded via a dedicated
strategy handler. This approach simplifies both the Transit and Metro
codebase while introducing some breaking API changes. Generally speaking
the changes are minor in nature and will normally be limited to test cases
that reference directly DPML part management APIS. In most cases these API
changes will not impact client code.
Under the 1.X series of distributions all classes were packaged under the
net.dpml namespace. Under 2.X public classes (i.e. classes making up the
public SDK API) remain in the net.dpml namespace whereas private classes
have been moved to the dpml namespace. This change resolves issues related
to public classes that were public in order to support inter-module
visibility but which were not designed for inclusion within the public API.
As a consequence - the public API for component management within embedded
applications has shrunk dramatically (37 public packages reduced down to 9).
This change to some extent is pre-emptive of the changes that would be
brought about by an implementation based on the JSR 294 Modularization
mailto:mcconnell at dpml.net
More information about the support-dpml