avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: RES: [RT] Block Packaging
Date Tue, 04 Nov 2003 03:29:34 GMT
On Tuesday 04 November 2003 01:33, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >Merlin of today does not require, nor support any package format (like SAR
> >with Phoenix), correct?
> The answer is mixed.  First off - Merlin supports a packaged model
> called a bar file.  A bar file is basically archive of a repository
> branch. This allows deployment of applications.
> For example:
>   $ merlin -install http://dpml.net/james/james-server.bar
> Merlin bar file should be viewed on one hand as integral with repository
> management, but on the other-hand it can also be referenced as a logical
> unit of deployment.

Hmmm. I think this is good. Haven't found a doc about it. Pointer?

> >* Each component is completely self-contained in a zip/tar/jar, and
> > dropped into a "components/" directory.
> Can I translate this to - "Each component is completely self-contained in a
> [bar], and [expanded] into a [repository]?

Also can (as they say in Malaysia). I just need to take a look at the .bar 
capability as it is, and see if any amendments should be recommended.

> >* Each of the component can have a default configuration, name
> ><classname>.xconf. There are no schema/DTD requirement, and I think it is
> >outside the scope to analyze source code, so is it a reasonable limitation
> >that the default configuration contains the FULL configuration tree?
> <classname>.xconf is the static default configuration.
> The actual configuration is a function of :
>   * the default
>   * a profile supplied configuration
>   * any embedded configuration declaration in a component directive
>   * any configuration assigned from a named confiugration target

Ok. I'll try to keep all of that in mind. A "named configuration target" is an 
external file, right?

> >Issues
> >* The following entries in distributed  Type Descriptors have been found
> > that I don't fully understand;
> >	<extension>
> >	<attributes>in <dependency>
> >	<stage> & <lifestyle>  is this experimental?
> >	<logger>
> * <stage> declares a deployment dependency on an <extension>
> * <extension declares the ability to fulfill a <state> dependency
> * <attributes> in <dependecies> are not used today but will be
>   supported in the future using regual expressions to add
>   fin-grain selection of candidates when handling auto-assembly
> * <lifestyle> declares the policy asumptions the component has
>   concerning creation semantics
> * <logger> declares child categories - can be used by a management
>   application to modify priorities and targets at runtime

I will not support all of the above initially. Anyone objects, I'll send a lot 
of KISSes ;o)

> >* Maybe it is because it is late and I'm very tired, but right now I don't
> >grasp "config.xml targets".
> Imagine you have a container called "test" hiolding a component called
> "demo" - e.g.
>   <container name="test">
>      <component namer="demo" type="MyDemo">
>        <configuration>
>           <location>Paris</location>
>        </configuration>
>     <component>
>   <container>

> Now if you want to modify the configuration of the demo component
> (without modifying the deployment directives) - you use a <target>. E.g.
>    <targets>
>       <target path="/test/demo">
>          <confiiguration>
>             <location>New York</location>
>          </configuration>
>      </target>
>   </targets>

> This is *really* handy because I can do things like pull in a container
> description for some complex system (e.g. James) and apply my personal
> adjustments to different components in the james system.  Each
> adjustment is made to a named component (the path attribute).  Currently
> the target can contain logging priority changes and configuration
> changes.  Think of the <targets> set as little scripts to tweak the
> meta-model established by Merlin.

Ok, let me see if I get this straight. Still confused over the "test/demo" 

I have a component named A, which sits deep inside a container structure of D 
contains C contains B contains A.

Are you saying that the "target" then maps the path, for instance in the 
block.xml file, to A, by
<target path="/D/C/B/A">

Would it also mean that C, could contain a target to A as well??

Maybe the fog in my head clears a bit more when I have to worry about the 
exact details...

> >* I'm staring at the UML diagram at
> >http://avalon.apache.org/merlin/merlin/index.html and trying to figure out
> >what appliance and block really is in Merlin terms, but no coins are
> > falling in place.
> Strinctly speaking:
>   Appliance == the object that manages instances of a partiular
> deployment scenario
>   Deploy Scenario == a component type + config + params + context, etc.
>   Block == the object that manages a container
> Different implementations of block can do different things.  The default
> implemetation provides for the creation of virtual serrvices by using a
> set of appliances together with a bunch of directives.  Other block
> implementations could provide different virtual services.

Is it only me, or is this confusing or not, especially since "Block" and 
"Component" has very loose definition in our daily conversations.

Fridge/toaster/aircond = Appliance = DeploymentScenarioManager ?
Lego/Brick/Chunk = Block = ContainerManager??

One day maybe, I'll get it ;o)


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

View raw message