Niclas Hedhman wrote:
On Monday 03 November 2003 22:49, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
The png is 45k and the jar was 13k... and that was too big.I fell your pain. Maybe the server doesn't like you at all >;-)
It doesn't matter... I have my own server... ;o)
FYI, I have taken the tact "specification by example", so I am pushing ahead creating some very simple plug-ins for Eclipse to aid in Avalon/Merlin development. But since I am not a killer programmer in general and not for Eclipse in particular, it will take a while.
If we start looking at the "end", i.e. Assembly of a Merlin app from N number of Components.
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.
I don't have a problem with that. A complete application could be unzipped manually, which IMHO is good enough. I suggest we don't worry about it for now.
I am targetting to solve the following objectives with the Eclipse plug-in(s) at this level in the near to medium term;
* 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]?
The plug-in will pick-up the components in each of the files in that directory. Each component can expose zero, one or many services. Further it can depend on zero, one or many services.
All this information is located in the Type Descriptor, which is (still?) <classname>.xinfo
<classname>.xinfo or <classname>.xtype
It will build a Component Repository, a Service Repository and a Service Dependency tree in memory.
Yep. (composition api)
* 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
I think the benefits over-weigh the downsides. I would think most people do this anyway, since they would need configurations for test purposes.
* Profiles are something new that I have been able to miss. But it seems like a reasonable feature to support at IDE level.
++1
If there is a .xprofile available, the assembler will be given the choice to select a profile.
Issues
* I realize that I don't understand the "Overriding" feature. Need some better description than http://avalon.apache.org/merlin/starting/tutorial/config/override.html
I'm not too happy with that particular tutorial either!
* I am not comfortable with Maven, so the plug-in will harness Ant instead. For the time being, I think Ant will do more than well.
* 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
* 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.
* 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.
But keep in mind that this is advanced-magic!
;-)
My main PoV is revolving around the issue of "Class vs Object".
What is the "component code" and what is the "component instance" called in Merlin terms?? I think I need some serious terminology here.
Ummm, its called a "component instance". Just remember that an Appliance manages between 0..n component instances - where each instance shares the same deployment scenario. Yep - I know that isn't very helpful.
Cheers, Steve.
I need to go and sleep. Cheers 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]
