Re: .xinfo

[Stephen McConnell]

Niclas Hedhman wrote:

Hi,

The .xinfo files that Phoenix expect have a different format from the ones 
that Merlin expect (or so the documentation says).

Merlin;
<type>
 <info>
   <name>simple</name>
   <version>1.0.0</version>
   <lifestyle>singleton</lifestyle>
 </info>
 <dependencies>
   <dependency key="random" type="tutorial.RandomGenerator" version="1.0.0"/>
   <dependency type="tutorial.Identifiable"/>
 </dependencies>
</type>
Phoenix;
<blockinfo>
   <block>
       <version>1.2.3</version>
   </block>
   <services>
       <service name="com.biz.cornerstone.services.MyService"
                version="2.1.3" />
   </services>
   <dependencies>
       <dependency>
           <role>com.biz.cornerstone.services.Authorizer</role>
           <service name="com.biz.cornerstone.service.Authorizer"
                    version="1.2"/>
       </dependency>
       <dependency>
           <!-- note that role is not specified and defaults
                to name of service. The service version is not
                specified and it defaults to "1.0" -->
           <service name="com.biz.cornerstone.service.RoleMapper"/>
       </dependency>
   </dependencies>
</blockinfo>
Shouldn't these be the same?

The Avalon Meta package defines the xinfo content as <type> which is a 
superset of the information contained with a <blockinfo> descriptor.  
The meta info readers included in the Avalon Meta package include legacy 
handlers that transform <blockinfo> descriptors into the standard Type 
instance.  This ensures that users of binary distributions of Avalon 
components are supported.

If not, how come this is not part of Avalon Framework specification from the 
beginning?

Evolution.

The framework started off focussing on the client view of the contract.  
As the framework developed a few notions of meta info started to slip in 
under marker interfaces. This evolved through a couple of iterations of 
meta descriptions.  The current incarnation - the Avalon Meta package, 
in conjunction with the framework specification repesents a broader and 
more complete defintion of the componet/container contract.

Stephen.

Niclas

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

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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