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? Does Merlin still use the .xinfo file, because I remember seeing <dependency> tags somewhere else? 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. 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]
