Re[2]: [GUMP] Build Failure - excalibur-datasource <--- fortress dep ?

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Stephen!

SM> Why does the excalibur datasource build have a dependency
SM> on the fortress container?

PR> Probably for fortress' meta-info generation.

SM> I recommend we remove the fortress dependency and include any meta info 
SM> needed by fortress as a static artifact in CVS.  This is the same 
SM> approach that is used in the cornerstone components - i.e. no container 
SM> dependencies.

SM> What do you think?

This already happens with SourceResolver
since the dependency graph is

    datasource - > fortress - > sourceresolver

See how it works there. (It's mainly in fotress-meta.xml
file). If sourceresolver finds fortress-tools.jar it
generates the metainfo, if it does not it uses the
cvs-supplied one. Also at every build if fortress-tools.jar
is found the files under src/fortress-meta are regenerated.

There have been talks on how to do this.

One idea was to have a separate excalibur sub-project
to concentrate meta tools, but it has yet to shape out
probably (if it will ever be created).

The code in sourceresolver that does this fortress-meta
fuss is mine and Berin has characterized it as "looking
more like a hack". However we agreed that it was the
best that could be done. (The matter was holding fortress
release then.)

Whether we want this "hack" to be copied to
* datasource
* monitor
* event
(all these also depend on fortress-meta.jar) or not
is a question.

It can be done, but this will probably mean that the
fortress-meta.xml file will be cloned 4 times. Brrr...

Maybe yet start a meta-tools project somewhere.
(avalon-excalibur? avalon/tools?)
We could move fortress-meta.xml file there.
A similar file can be written for generating Phoenix
meta. Okay it is not a full blown meta-generationg
subproject, but it will be better then nothing, will it?

-Anton


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

Re[2]: [GUMP] Build Failure - excalibur-datasource <--- fortress dep ?

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Stephen!

1)

SM> Why is fortress-meta dependent on Fortress?

I think they share the

    org.apache.avalon.fortress.MetaInfoEntry
    org.apache.avalon.fortress.util.dag.Vertex
    org.apache.avalon.fortress.util.dag.CyclicDependencyException
    org.apache.avalon.fortress.util.dag.DirectedAcyclicGraphVerifier

classes, don't know how to separate...

What makes it worse, I have just come back from vacations
and haven't got well planted in the new build system in
general and maven in particular..

SM> Can they be more cleanly seperated?
SM> Can Fortress meta be migrated to the meta package?

2)

SM> Meta info (details about a component type) should be very closely 
SM> aligned with the framework.
SM> Tools to produce this meta-info should be totally container independent.
SM>
SM> Meta data (details about deployment of a component or set of components) 
SM> are much more closely aligned with a particular container.
SM>
SM> A common meta-info model that is container independent and addresses the 
SM> complete set of requirements across the three avalon containers is all 
SM> that is needed. Any tools that are container specific should remain with 
SM> the container that they are specific to.

Thanx for updating me on the terminology and the ideas! :-)
It has really been a long mail, but know I got to understand that
the terms meta-info and meta-data are used differenlty. And indeed
this has been a very clear description of which is which

3)

A practical short-term solution about fortress meta data seems to be:
"let the fortress meta data generation code remain "married" to
fortress".

But our original goal was to make a handful of excalibur subprojects
to compile both with and without fortress (in the latter case using
pre-generated meta-data).

This may be achieved by use of fortress-meta.xml ant script currently
located in sourceresolve. However I'm at a loss where to move it to
make it accessible to
  * sourceresolve
  * event
  * monitor
even when we have no fortress available.

On the other hand probably it's better to leave these projects
dependent on fortress for a while? It seems that it was some
other trouble, not a circular inter-project dependency error
that caused the failures, wasn't it? Just some side-effect of
migration to maven?

-Anton


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

Re: [GUMP] Build Failure - excalibur-datasource <--- fortress dep ?

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

Anton Tagunov wrote:

>Hello Stephen!
>  
>

Hi Anton:

>SM> Why does the excalibur datasource build have a dependency
>SM> on the fortress container?
>
>PR> Probably for fortress' meta-info generation.
>
>SM> I recommend we remove the fortress dependency and include any meta info 
>SM> needed by fortress as a static artifact in CVS.  This is the same 
>SM> approach that is used in the cornerstone components - i.e. no container 
>SM> dependencies.
>
>SM> What do you think?
>
>This already happens with SourceResolver
>since the dependency graph is
>
>    datasource - > fortress - > sourceresolver
>
>See how it works there. (It's mainly in fotress-meta.xml
>file). If sourceresolver finds fortress-tools.jar it
>generates the metainfo, if it does not it uses the
>cvs-supplied one. Also at every build if fortress-tools.jar
>is found the files under src/fortress-meta are regenerated.
>
>There have been talks on how to do this.
>
>One idea was to have a separate excalibur sub-project
>to concentrate meta tools, but it has yet to shape out
>probably (if it will ever be created).
>
>The code in sourceresolver that does this fortress-meta
>fuss is mine and Berin has characterized it as "looking
>more like a hack". However we agreed that it was the
>best that could be done. (The matter was holding fortress
>release then.)
>
>Whether we want this "hack" to be copied to
>* datasource
>* monitor
>* event
>(all these also depend on fortress-meta.jar) or not
>is a question.
>  
>

Why is fortress-meta dependent on Fortress?
Can they be more cleanly seperated?
Can Fortress meta be migrated to the meta package?

>It can be done, but this will probably mean that the
>fortress-meta.xml file will be cloned 4 times. Brrr...
>
>Maybe yet start a meta-tools project somewhere.
>(avalon-excalibur? avalon/tools?)
>

Meta info (details about a component type) should be very closely 
aligned with the framework.  Tools to produce this meta-info should be 
totally container independent.  I think that this sort of content should 
eventually be colocated with the framework - e.g.

   avalon
      framework
      meta
      tools

Currently the meta-info models are different across all containers.  
Fortress uses text file called <classname>.meta into which the component 
type name is written along with services that the component provides. 
Dependencies are stored in a seperate <classname>.deps.   Entries in 
both files a delimited by line breaks.  Phoenix provides the 
<classname>.xinfo file which is XML based and provides additional 
information coverning management access points and configuration 
schemas.  The meta used in Merlin provides support for serialized and 
XML descriptors under the <classname>.xserial and <classname>.xinfo.  
The meta package contains additional information the covers context 
criteria (enabling things like the declaration of the Phoenix context 
casting assumptions and context entry assumptions), declaration of the 
logging categories used by a component, and the ability to associate 
attributes to features of the component type.

Relative to the existing approaches the meta package comes closest to 
meeting the full suite of meta-info modelling requirements, although 
this still needs to be enhanced to capture JMX management access points 
and configuration schema references.

Under the meta package the existing tools provide support for the 
construction of a meta-info object model based on javadoc tags.  The 
meta-info model can then be externalized into either xml or serialized 
form (and in the future - any other persistent storage model we want to 
come up with).

Meta data (details about deployment of a component or set of components) 
are much more closely aligned with a particular container.  For example, 
Phoenix meta-data includes the assembly.xml and configuration.xml files, 
Merlin uses block.xml in conjunction with .xprofile directives.   
Fortress has it role files.  In each case the meta-data reflects the 
logic and feature set of the containment environment.  As such, this 
isn't a something we should be trying to standardize today (it much more 
interesting to get meta-info sorted out).

>We could move fortress-meta.xml file there.
>A similar file can be written for generating Phoenix
>meta. Okay it is not a full blown meta-generationg
>subproject, but it will be better then nothing, will it?
>

A common meta-info model that is container independent and addresses the 
complete set of requirements across the three avalon containers is all 
that is needed. Any tools that are container specific should remain with 
the container that they are specific to.

Cheers, Steve.

-- 

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