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" 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"> ?? 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) Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
