Return-Path: Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 93979 invoked by uid 500); 20 Aug 2003 07:10:18 -0000 Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list dev@avalon.apache.org Received: (qmail 93575 invoked from network); 20 Aug 2003 07:10:04 -0000 Received: from unknown (HELO f1.internuscorp.com) (211.24.132.29) by daedalus.apache.org with SMTP; 20 Aug 2003 07:10:04 -0000 Received: from hedhman.org (f1.internuscorp.com [211.24.132.29]) by f1.internuscorp.com (8.12.8/8.12.8) with SMTP id h7K6Y73V024487 for ; Wed, 20 Aug 2003 14:34:08 +0800 From: Niclas Hedhman Received: from 211.24.132.30 (SquirrelMail authenticated user niclas) by www.hedhman.org with HTTP; Wed, 20 Aug 2003 14:34:08 +0800 (MYT) Message-ID: <3225.211.24.132.30.1061361248.squirrel@www.hedhman.org> Date: Wed, 20 Aug 2003 14:34:08 +0800 (MYT) Subject: Re: Blocks made of Blocks To: In-Reply-To: <3F423160.3080106@apache.org> References: <3517.202.146.68.8.1061290804.squirrel@www.hedhman.org> <3F420726.6030209@apache.org> <3F423160.3080106@apache.org> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 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 directives inside the > 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: >> >> >> >> >> >> >> >> >> >> >> >> >> 2. create a composite component model that includes the simple model. >> >> >> >> >> >> >> >> >> >> > >> >> >> >> 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: dev-unsubscribe@avalon.apache.org >>> For additional commands, e-mail: dev-help@avalon.apache.org >>> >>> >>> >>> >>> >> > > -- > > Stephen J. McConnell > mailto:mcconnell@apache.org > http://www.osm.net > > Sent via James running under Merlin as an NT service. > http://avalon.apache.org/sandbox/merlin > > > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org > For additional commands, e-mail: dev-help@avalon.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org