It's obvious that there are some issues to work out. That's OK. experiments like this help us expand our minds and learn. What's wrong with getting some impirical evidence? In the end, how much of this will save time in development, etc.?
It may be that the current approach of scanning all the classes in a JAR file is the wrong solution. Avalon has a need, so how do we solve it?
With Fortress, we used a Java standard for identifying all the components that implement a service. This packaging standard works. I put the basic ANT task to collect implementations of a service in the ANT BugZilla. It works. The next fundamental problem was how do we know what services are available? I did the next simplest thing: added a list in META-INF/services.list so that we could discover the components by iterating over the services, and then finding the components that implement the service.
With Merlin, it uses the Manifest (another Java standard) and marks certain classes and interfaces as an Avalon Type or an Avalon Service.
Both approaches work. The Merlin approach requires you to explicitly parse the Manifest (which intails looking at the JarFile, getting its Manifest, and using the Manifest object to parse the contents). Fortress allows you to work with a set of files that are no more than a list. You to simply use the getResource() or getResources() methods to get the lists.
Both of these approaches try to comply with a standard that is already present in Java land.
So the main issue is that I think we have determined that we cannot solve this elegantly simply with the Attributes mini-project. We can solve all other problems that meta info solves easily with the project. We may have to choose a standard for Avalon JAR files. Whether it is the Merlin approach or the Fortress approach doesn't really matter, as long as we can get the information. Whatever scales the best works works the best.
The Phoenix approach is that the assembly identifies all the components that are going to be used anyway, so it is unaffected by any packaging standard. It does not determine dynamically what components are available. This is OK as long as the server never changes ;P.
<snip type="squibbling"/>
I am OK with this. It's important that we know when to say, "OK that's enough".
--
"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]
