Leo Sutic wrote:
The real subject is about:
* external format evolution
being able to evolve gracefully from version X to version Y of an externalized meta descriptor (which concerns both meta-info and meta-data)
* external format extension
being able to supplement the model - but the actual requirements here seem somewhat foggy to me as extension add semantics that are known by some container-side handler so in practice anything is already possible
Simplicity guys. Simplicity. If there is no "external format", and only the source code, then I see no reason to worry about these concerns. I have the feeling that we are worrying about the wrong concerns. The whole idea of "external" meta info other than source code is IMO flawed. This is where the concept of the *intermediate form* of XML has really caused us to be short sighted.
We need to identify WHO the user is of the meta info, WHAT tools will use it, and HOW the tools expect to get it. If the tools are IDE extensions, the safe bet is that they are a Java IDE with tools written in Java--which means that compiled meta info is a winner. Conversely, in the arena where this is not even an issue, the C# Avalon, it is compiled meta info. Why should we complicate matters on the Java side?
If we are talking about automated "requests for help", can we identify WHAT tool will generate this request? It will likely be either an IDE extention, an (N)ANT task, or something of that nature. I am still failing to see why we need the XML panacea. It is the wrong tool for the job IMNSHO.
Lastly, I get the feeling that this XML format is trying to be the full specification of everything related to that component, whether or not it is directly related to the contracts as a component *to* the container. If there is a tools based meta info, why should that tool rely on being able to extend the XML format for its purposes? Why not just have it *work*?
See the difference here?
What is most important to you is of course the factor that decides. The goals for C-A made the design of it what it is.
It is absolutely not impossible to access the metainfo from non-Java applications. It can be exported to XML, CSV or whatever format. It's just heavily biased toward easy access from Java as an extension to the reflective API.
Can we explore the above sentence a little. What I'm interested in understanding is *if* and where the connections *should* exist. If I image a scenario where a model aspect handler is added as part of the internal container system - I can see two possible approaches:
1. it uses a supplied Type to get information (such as the class name of the component) to handle the internalization of a model (using whatever technology is appropriate)
2. there is a generic method with the Type to provide convenient access to supplementary model information
WDYT?
I think that solution is putting too much into the the "Type" system. There is already a way to manage these things in Commons Attributes with a normal reflective API. If we need to get the info straight from the source code, then we have the JavaDoc tool to extract it for us.
KISS
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
