Niclas Hedhman wrote:
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?
Umm, sorry - no.
I havn't created docs on this because I think we still have a lot to do. Installation is fine but what I really want is executable blocks and that requirtes a few more parameters to be included in the bar manifest. Which leads me to the note that to get an idea about how a bar works - just take a peek at the manifest.
* Each component is completely self-contained in a zip/tar/jar, andCan I translate this to - "Each component is completely self-contained in a
dropped into a "components/" directory.
[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.
There is room for development. :-)
* 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?
A named configuration target is declared with a <target> element. A set of <target> elements are contained with a <targets> element. The filke containing the <targets> element is the configuration file you pass to merlin using the -config argument.
Issues* <stage> declares a deployment dependency on an <extension>
* 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>
* <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)
Careful, my wife will get jelouse!
* 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" path...
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">
??
Yes.
Would it also mean that C, could contain a target to A as well??
Yes.
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 atStrinctly speaking:
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.
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 ?
Fridge configured to cold, toaster parameterized to off, aircond with context "to be fixed" are examples of deployment scenarios. And appliance manages exactly one deployment scenario.
Lego/Brick/Chunk = Block = ContainerManager??
Broken airconditioner causes tempterature to rise nagating need for toaster and exclating functional requirement to set fridge on high - resulting in perfect harmony thanks to an inteligent Block that is sorting out the things that happen relative to particular objective.
:-)
One day maybe, I'll get it ;o)
LOL
Stephen.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
