Niclas Hedhman wrote:
Stephen McConnell said:
You have to excuse for; 1. Not having Internet access at home, 2. so I couldn't build Merlin last night, 3. nor browse the online documentation.
Bear with me.
Is the block.xml the equivalent of Phoenix's config.xml + assembly.xml?
Sort of.
The significant differences are:
1. you don't need to specify the connections unless you really want to - merlin provides automated assembly which is sufficient for 98% of cases - and for that additional 2% you can either declare connections between providers and consumers explicitly
2. you don't have to declare a configuration because you can package these with a component (defaults), and/or leverage packaged profiles, and/or override these - which means that you end up with much simpler deployment model
3. you can include deployment models from external sources - for example, I could include a deployment descriptor from your site as the defintion of a sub-system within my deployment descriptor
Does Merlin still use the .xinfo file, because I remember seeing <dependency> tags somewhere else?
Merlin understands and reads in Phoneix style .xinfo descriptors to construct meta-info objects. The preferred approach is to use the more complete definition that is part of the Meta package (in sandbox but nearing release).
FYFC (For Your Future Consideration), There are more to a Block than a JAR file, and Avalon should start the effort to define how I can bundle the Block CODE, with documentation and web resources/app. Part of the "bundling issue" is how these additional stuff integrates with each other, for instance; If I write a Block Specification and the Documentation of it. If I then can bundle this into a single TAR/JAR/whatever, and when I create the Block Implementation I drop that TAR/JAR/whatever into src/spec/ or something, and "my tool" integrates the Spec docs/javadocs with the Impl docs/javadocs and all the other stuff into a complete Block TAR/JAR/whatever, which can later as easily be dropped into src/blocks/ in the application, and I add some configuration and wiring there, and again build the complete system.
I am working on all of this and realize that there is an enormous potential of productivity boost if this can be achieved. But maybe it is only I who work in a field where new apps are created rapidly, and everyone else works on projects that starts and then takes months or years to complete.
Your not alone! Where things are today in the Merlin model is a level of abstraction below the sort of thing your talking about. However, I think the combination of the Meta Info API and the Compposition API from Merlin would provide some very powerful tools for manipulation and maangement of the deployment aspects of composte applications. If the same sort of logic was applied to the overall packaging solution, then it is easy to imagine a rather complete component management framework emerging from the dust.
Stephen.
Niclas
From the Merlin composition tutorial.
Composition Management ======================
Overview --------
This tutorial presents the creation ofn virtual components using composition of package containers. In this demonstration we have three application groups, a top level application, a locator system, and a publisher system. The top level app pulls in the two sub-systems as virtual components. The sub- systems are themselves fully deployable blocks in their own right (although in this demonstratotion they represent very simple sub-systems). In practice, the combination of packaged deployment profiles, default configurations, auto discovery, auto assembly, and block composition provides a powerful framework complex systems delivery.
Build and execution instructions: ---------------------------------
$ maven build $ merlin application\impl\target\*.jar -system %MAVEN_HOME% -execute
[INFO ] (application.publisher.publisher): created [INFO ] (application.location.info): location: Paris [INFO ] (application.application): servicing application [INFO ] (application.location.info): location: Paris [INFO ] (application.publisher.publisher): created [INFO ] (application.publisher.publisher): ****************** * Paris ****************** [INFO ] (application.application): done
Use the following command to include container debug level log entries for the demanding developer.
$ merlin application\impl\target\*.jar -system %MAVEN_HOME% -execute -config application\impl\conf\config.xml
Summary -------
The purpose of this demonstration is to show how the container can be viewed as an implementation strategy for the creation of a virtual service, and how these service can be composed within a higher level containers, enabling new implementation solutions. The key to achiving this is related to the <service> directives inside the <container> direective. Each service directive describes a service that is exported by the container in its role as a virtual component.
Stephen McConnell wrote:
Composite components from the Merlin point-of-view:--
1. create a simple containment model:
<container name="simple"> <classloader> <classpath> <resource id="demo:simple-api" version="1.0"/> <resource id="demo:simple-impl" version="1.0"/> </classpath> </classloader> <component name="demo" class="Demo"/> <!-- any other componenents or nested containers --> </container>
2. create a composite component model that includes the simple model.
<container name="composite"> <classloader> <classpath> <resource id="demo:simple-api" version="1.0"/> <resource id="demo:complex-api" version="1.0"/> <resource id="demo:complex-impl" version="1.0"/> </classpath> </classloader> <include id="demo:block" type="xml" <component name="complex" class="AnotherComponent"/> <!-- any other componenents or nested containers --> </container>
Note that the composite container inlcudes the API classes from simple. This ensures that the API content from simple is included in the classloader that the composite container is running within. Containers in Merlin look like components to other components and participate as components during assembly.
A practicle example of this approach to composition is included in the james containment model within which there are about three level of composition mainly dealing with the cornerstone components (some of which are composite). This also allows James to be exported as a component and participate as a peer in higher level assembly and deployment processes.
CHeers, Steve.
Niclas Hedhman wrote:
Hi,
I am working on the higher-level concept of assembling existing components into higher-level components and exposing that assembly as a new Block.
There are several ways to do this, and I would appreciate any comments from others who have looked into this.
1. A tool can map the outer-layer config into the config expected by the inner-layer blocks, prior to packaging the SAR (for Phoenix). Vice versa, it can rip out the inner-blocks assembly and transfer it to the SAR assembly.xml prior to packaging.
2. The higher-level component can wrap a container inside and transfer the outer-layer config to the inner-layers at runtime. The assembly of the inner-layers are handled completely by the embedded container.
As for 1, I can manage to get this to work, but it seems like "the wrong way".
As for 2, I can not manage. Phoenix is out of the question as the embedded container, and I don't know how to go about using Merlin as the embedded container and Phoenix as the app container.
Perhaps there are other alternatives.
Shouldn't this whole issue be addressed by Avalon at its core?? If I can't create components made of other components, we will never manage to build very large re-usable system components.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
