[transit] update on the refactored repository package

[Stephen McConnell <mc...@apache.org>]

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: [transit] update on the refactored repository package

[Stephen McConnell <mc...@apache.org>]

> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: 12 September 2004 11:38
> To: Avalon Developers List
> Subject: Re: [transit] update on the refactored repository package
> 
> On Sunday 12 September 2004 13:55, Stephen McConnell wrote:
> 
> > 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.
> 
> Sounds like a great job. Can't wait to see the code materialize inthe
> subversion repo...
> 
> But I am wondering if there is one more step needed, or if that is
> overkill;
> 
> You say that the metro-transit-plugin handles the command-line
arguments
> as
> well as a repository cache controller. Wouldn't it make a LOT of sense
of
> separating these, so that other applications can create there own
> command-line parsing, but have the repository controller as-is,
without
> fokkering around with Metro Transit code?

I'm handling this concern by setting the cli parser to stop on
unrecognized options.  This results in the parser chewing its way
through the controller args until a non-recognized option is found.  The
non-recognized option and all subsequent options are available as
arguments to plugins and resources loaded by the controller.

Example:

$ metro -load plugin:somegroup/something#1.0.0 -xyz abc

In the above case the '-xyz' option is not recognized, so we end up with
'-xyz' and all subsequent cli values as a parameter for loaded plugins.
A more practical example would be something like:

$ metro -load plugin:avalon/merlin/avalon-merlin-impl#3.3.0 widget.block

In the above case widget.block is recognized as unrecognized and will be
supplied as a possible constructor argument to the merlin plugin.

> It is a bit hard to get the picture without some diagrams and code :o)

That's life!

Cheers, Steve.


> 
> Cheers
> Niclas
> --
>    +------//-------------------+
>   / http://www.bali.ac        /
>  / http://niclas.hedhman.org /
> +------//-------------------+
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [transit] update on the refactored repository package

[Niclas Hedhman <ni...@hedhman.org>]

On Sunday 12 September 2004 13:55, Stephen McConnell wrote:

> 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.

Sounds like a great job. Can't wait to see the code materialize inthe 
subversion repo...

But I am wondering if there is one more step needed, or if that is overkill;

You say that the metro-transit-plugin handles the command-line arguments as 
well as a repository cache controller. Wouldn't it make a LOT of sense of 
separating these, so that other applications can create there own 
command-line parsing, but have the repository controller as-is, without 
fokkering around with Metro Transit code?

It is a bit hard to get the picture without some diagrams and code :o)

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org