avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Blocks made of Blocks
Date Wed, 20 Aug 2003 06:34:08 GMT
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: 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


Mime
View raw message