Avalon needs a future, and there are a number of possibilities ahead that will really make things work nicely. This is not a bad situation to be in. I remember in the past that we considered Avalon 5 to be synonimous with Java 1.5. There would be enough in the core language that we wouldn't have to rely on hacked together utilities that make using Avalon less appealing.
Avalon 4 today fits a certain number of needs, and that is great. Evolution is better than revolution in many respects. I think that is a perfectly natural way to move forward. But think about it, in Avalon 4 there is a bunch of cruft. It would be best to get rid of that cruft. So a fresh Avalon 5 approach does not mean coming up with all new interfaces for what you need to do. It means that you should trim the fat and work from there. In doing this, you can remove all the ties that bind you to those undocumented or back-compatibility traps that add to the bulk and complexity of the current crop of containers.
This is the first step of simplification. Tell me if I am wrong if that does not simplify the tool requirements.
Once we have cut to the core of what we need (no cruft), we can then focus on what we plan on enforcing. In the corner of meta-data/meta-info/ meta-whatever-you-want-to-call-it, I highly recommend you to read the docs for the new Java Annotations features. You will find that there are different types of annotations that are important. You cannot know what they are until you start playing with them. For the lazy:
1) Runtime annotations that are necessary to access using reflection on live objects.
2) Class annotations that are necessary to access using tools like code generators, IDE integration, etc. These are embedded in the class file, but not necessarily accessible through normal reflection.
3) Source annotations that the compiler generally ignores. They are good for documentation purposes, but little more.
Currently, all of the Avalon Meta project falls into the first class of annotations because they are accessed at runtime and remain in system memory during runtime. Some of those should probably be put into class annotations, or something along those lines.
Lastly, in the process of generating your tools and working with the system, you don't really know what meta info is going to be helpful to you until you start playing with it and get the "wouldn't it be nice if..." process going on. With things so hard coded at the moment, you can't really experiment nicely. This is the main reason for pushing the Java 1.5 annotations that I have. Sure you can define the set of annotations for Avalon 5 and make that part of the framework. I would really prefer it if you did. You still have a well defined set of contracts, but you also have some room to expand to support different tools.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
