Transit provides a flexible framework for dynamically
retrieving system and application resources, constructing
classloaders and management of plugins via
an abstract resource identifier referred to as an artifact.
As a resource management system Transit provides the foundation
for building repository-enabled applications.

One of the more difficult tasks when building Java applications
is classloader management. Often, when combining various projects
together into an enterprise application, the application is not
able to load the right classes at the right time, causing the
application to fail in mysterious and sometimes subtle
ways. Although a fundamental issue, classloading has remained
a rather obscure topic. When combined with component-based
development the classloader management concern can become a major
configuration management concern.
Transit provides a solution to this problem.

At the core of Transit is a URL protocol handler and a framework
for custom content handlers. Content handlers provided by DPML
include a deployment system that encapsulates a classloader defintion
and deployment strategy, together with a handler supporting the
establishment of a Java runtime process.
Based on these, Transit is able to manage classloaders, not only
effectively and nearly invisible to the casual user, but in a location
independent way. That means, applications don't need to be concerned over
where the jars and other resources are located, whether on the local file
system, on LAN servers or somewhere on the Internet.
This allows an application to provide extendability, hot-redeployment
and more advanced services.

Transit Artifacts

Each artifact has a unique identifier conforming to the Transit
artifact protocol specification.
Using a standard extension to the java.net.URL class in the Java API,
Transit accesses an artifact through an artifact URI.
The artifact URI logically identifies a resource and the Transit
system provides the means for resource retrieval.

The artifact URI describes the:

type of resource (JAR, meta, template...)

group to which the artifact belongs

name of the artifact

version

The purpose of the group is to avoid naming conflicts in the artifact
name space. The top level group should be a distinguishable and well
accepted name of the organization, and any sub groups to be decided
by the organization itself to further avoid name clashes.
It is recommended that the bottom level group is the release level, i.e.
all resources within the 'release' shares the same version and are
meant to be working in a group within that version, and not mixed
between versions.

Transit promotes strong version management. The underlying concern is
that many parts of the system are dependent on particular versions of
another part or resource, and can not be freely mixed. To ensure
that all dependencies are resolved against the proper versions, it is
paramount that a version management system is in place, and policies
are established. From Transit's point of view, the version is an
opaque identifier without any in-built semantic meaning.

These identifiers disassociate the definition of an application
from the source of the resources needed to build and deploy the
application. Meaning, it is only in the interest of the user of
the resources, be it built tools or running applications, that the
correct resources are provided, and not from which
server these were downloaded. The task of resolving the location
is transferred from each application to Transit itself, which is
configured to know about which servers are available in its running
environment.