Fortres META dependencies

[Leif Mortenson <le...@tanukisoftware.com>]

Hi all,
I have been running into some problems that have been tracked down to the
way Fortress's META task is currently collecting its META information.

I have a series of classes A, B, and C. Each implements a service method
which declares a single dependency. C extends B, and B extends A. Each
of the classes exists in a different source tree and thus different jar.

As things are right now, both A and B are abstract classes and thus do not
contain the component headers. When META parses these files, it does not
create the .deps files in the jars for A or B. When it is time to build
C, the
source and thus the original dependency information is no longer available.

What are your thoughts on how to solve this?

My thinking is to modify the META task so that .deps files are generated
for all classes which define dependencies, regardless of whether or not they
are components. This way the jars would contain A.deps and B.deps.
Then when the C jar is being built, the META task would search for the
source of all parent classes. If the source for any one class could not be
found, it would look for the .deps file.

2)
A second issue is how dependencies should be declared in classes which
do not directly implement Serviceable? In the above A->B->C example,
A.service is implemented and then provides an A.getServiceManager()
method. Ideally, I would rather not have to extend the service method
in B and C to declare their additional dependencies. Currently, I am
doing the following:
/**
* Provide the component with a reference to its ServiceManager so
* that is can obtain references to other components needed for
* execution.
*
* @param serviceManager The ServiceManager controlling this component.
*
* @throws ServiceException If there were any problems.
*
* @avalon.dependency
type=org.apache.avalon.excalibur.datasource.DataSourceComponent
*/
public void service( ServiceManager serviceManager )
throws ServiceException
{
super.service( serviceManager );
}

What about the idea of modifying the META task so that it looks for the
@avalon.dependency tags both in the service method javadocs and in the class
javadocs. This way they could simply be defined at the top of the class.

Cheers,
Leif

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

Re: Fortres META dependencies

[Berin Loritsch <bl...@d-haven.org>]

Leif Mortenson wrote:

>Hi all,
>I have been running into some problems that have been tracked down to the
>way Fortress's META task is currently collecting its META information.
>
>As things are right now, both A and B are abstract classes and thus do not
>contain the component headers. When META parses these files, it does not
>create the .deps files in the jars for A or B. When it is time to build
>C, the
>source and thus the original dependency information is no longer available.
>
>What are your thoughts on how to solve this?
>  
>
Unfortunately, META as written needs the source code to all components
being collected.
If you have subclasses in another JAR file, you would need to include
the source for the
subclasses within the search path.

>My thinking is to modify the META task so that .deps files are generated
>for all classes which define dependencies, regardless of whether or not they
>are components. This way the jars would contain A.deps and B.deps.
>Then when the C jar is being built, the META task would search for the
>source of all parent classes. If the source for any one class could not be
>found, it would look for the .deps file.
>  
>
Do keep in mind that Fortress META is a substitute for Java Annotations.

>2)
>A second issue is how dependencies should be declared in classes which
>do not directly implement Serviceable? In the above A->B->C example,
>A.service is implemented and then provides an A.getServiceManager()
>method. Ideally, I would rather not have to extend the service method
>in B and C to declare their additional dependencies. Currently, I am
>doing the following:
>/**
>* Provide the component with a reference to its ServiceManager so
>* that is can obtain references to other components needed for
>* execution.
>*
>* @param serviceManager The ServiceManager controlling this component.
>*
>* @throws ServiceException If there were any problems.
>*
>* @avalon.dependency
>type=org.apache.avalon.excalibur.datasource.DataSourceComponent
>*/
>public void service( ServiceManager serviceManager )
>throws ServiceException
>{
>super.service( serviceManager );
>}
>
>What about the idea of modifying the META task so that it looks for the
>@avalon.dependency tags both in the service method javadocs and in the class
>javadocs. This way they could simply be defined at the top of the class.
>  
>
That's outside the contracts with Avalon contracts. The META facility
copied Phoenix's approach, but if you want to change that go ahead.


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