Have just about finished a refactored version of repository. It's
smaller, cleaner, and most importantly - more futureproof. Unlike the
current implementation, the package is broken down into two sub-projects
- main and plugin.
The main package (metro-transit-main) contains the bootstrap loader and
a command line handler with a classic main method. The main method is
responsible for the following set of actions:
1. Loading of metro.properties from the following sources:
${user.dir}
${user.home}
${metro.home}
2. Handling of proxy settings has been moved out of the repository
system
itself and is now handled by the main class using the following
property keys:
metro.proxy.host
metro.proxy.port
metro.proxy.username
metro.proxy.password
3. Creation of a bootstrap repository cache and loader that can be
customized with the following properties:
metro.cache
metro.hosts
metro.online
metro.timestamp
4. Creation of a repository cache controller using a plugin artifact
declared under the property key:
metro.controller
5. The plugin is supplied with the command line arguments as part of
the instantiation process (using patterns based on the experience
with instantiation under the logging package). In a break from the
existing repository model a plugin is not a factory but is
responsible for its own initialization (made possible by a stronger
constructor management model).
>From here on the behavior of the system is a function of the plugin that
is loaded. A default repository cache controller plugin is provided
(metro-transit-plugin). It is important to note that cli argument
passing is handled by the plugin (as opposed to the current model where
cli passing is handled prior to application loading). This means that
future versions of the plugin may expose different cli arguments and
implementation - but moving from one version to another does not require
modification of the bootstrap system.
The metro-transit-plugin is in fact just another repository
implementation but unlike the existing model, it can have whatever
dependencies it wants (such as logging, i18n, and all of those other
utilities we have) - and furthermore, these dependencies can evolve over
time. With command line handling under the control of the plugin there
is no longer a need for the criteria management model we currently use
or the Factory and Builder interfaces and patterns. In the case of
metro-transit-plugin I've added some special handling for a '-load' cli
option. This is equivalent to the creation of a repository and the
subsequent loading of a number of artifacts (which is exactly what we do
currently to load logging systems, the merlin kernel, activation runtime
etc.).
The -load argument takes a comma separated sequence of artifact uris
that reference other plugins - and this is where things get into that
fun area. Given a set of plugin refs, by implication we have a set of
services, and logically this means we have an assembly scenario. I.e.
we could order the -load arguments based on declared plugin services and
constructor dependencies and then .. apply some execution logic to the
respective plugins.
Currently I'm just loading the load arguments as classic artifacts (e.g.
jar files) - however, I've just created a fork of magic with the
intention of creating an antlib for metro, and from that antlib, booting
'magic' as a plugin. The implications of this are interesting -
firstly, the magic version is no longer in .ant/lib which means we
re-gain version control. Secondly, we can start doing things like
adding a jmx server to the controller plugin and from that, start
playing with remote controlling the controller, which implies remote
controlling the magic build system. With remote control of magic - we
can think about a suite of possibilities:
1. building/debugging client builds remotely
2. dynamic upgrading of magic on remote sites
3. using remote sites for platform dependent builds
Does this sound like something we should be considering?
Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
