I thought my original email had rationalizations and what good I had hoped to gain by changing the Meta package. However, it seems that I was not successful in communicating that yesterday. A couple of you got hostile and assumed I had no rationalization simply because I did not have the time to spell it out for you completely ad nauseum. That is what this email is for.
What is the primary problem? ----------------------------
The primary problem came from trying to integrate the package into Fortress so that we can use the same meta info in both Fortress and Merlin. It became painfully obvious to me that the certain divisions in the system seemed artificial and broken. How many different applications will actually use the meta info? Containers and tools. That's about it. Yet the model is separated from the writers and the readers--which both the containers and tools will need to work with the system.
Secondly, in order to support the Fortress meta info reading the package needs to be altered because it assumes one file to one component. In Fortress the meta info is split between two files--one for component info and one for dependencies. There was no simple way to change that.
Thirdly, in order to maintain the ability to automatically assertain which components were available to Fortress, I would have to have Fortress load the JAR files and scan them for the meta info. Fortress was originally designed to work in situations where the JAR files were already loaded into classloaders. Reloading the JARs just to scan them would be bad--esp. if you did not know where those JARs were.
Lastly, the XML panaceia syndrome. XML is a great tool for certain situations, but not for all. In the situation where we are recording meta info for components, the XML is verbose, and the parsing and generating overhead adds up. I suppose one could argue that the serialization solution is one way around it, but that will run into problems reading meta info generated from one JVM into another.
The conclusion is that there is no easy way to incorporate the meta package into anything besides Merlin where it makes all the assumptions that make the package a decent solution for it. Quite frankly the number of assumptions in the package, and the inflexibility of it to do ad hoc attributes of any deliniation (like @jmx.bean or @instrument name=foo) leads me to the conclusion that it is a special purpose library for a special purpose solution, and not the general solution it is touted for.
Why use Leo's Attributes Package? ---------------------------------
Leo's Attributes package is a much easier integration into any system. It does not require many different resource files like the Fortress and Merlin solutions do. It is neatly contained, and automatically handles any attribute without question or special coding to make it work. If I want a model for new attributes that are no where close to what the Meta package offers, I would have to make non-trivial code changes with impact on a number of systems.
Do I have specific examples of arbitrary attributes at this time? Not yet, but I do have a general idea of where I would want to use them. The thing is that inflexibility causes more long term harm than good. Rather than creating an environment that is as inflexible as a fascist, creating a system that deals with change provides better robustness.
My suggestion is not only for the current needs of integrating with Fortress, but for the future needs that *will* arise. In fact, it very well may help make these feature requests from JAMES and company easier to work with.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
