Part of the reason for failure of commons-attributes was that Jon was never invited to 
teh club.
Thus he just continued with attributes-in-nanning.

JFDI, might work, but it would be better to convince Jon to take attributes out of 
nanning.  I
need to make the no-logging point again though :-)

- Paul

 --- Niclas Hedhman <[EMAIL PROTECTED]> 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?
> 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]
>  

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to