.xinfo

[Niclas Hedhman <ni...@hedhman.org>]

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?
If not, how come this is not part of Avalon Framework specification from the 
beginning?

Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: .xinfo

[Stephen McConnell <mc...@apache.org>]

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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org