Leo Simmons posted a nice little essay that should be referenced prominently, although maybe tempered a little? Obviously, Leo has encountered too many applications that suffer from this overzealous application of magic. However, it begs some serious questions that we might want to look at with Avalon.
1) Are we going too far down the rabit hole, as it were? If so, where and how do we fix it?
2) How does a project that *is* a framework embrace such an outlook--carefully balancing what the framework is supposed to do and increase maintainability and debuggability (new word...) of applications built on it.
For instance, I like attributes, as it solves some very real problems with component management--although their use does provide some serious issues that need to be addressed.
Along with the introduction of attributes, and special config files, etc., making an application built with these tools work with a storebought IDE is difficult. I have really learned how to work with a debugger in the past few years, and creating a plugin just to make the application run is not really that cool.
We need to compile the attributes at compile time, and be able to work with the IDE's supplied classloader--which means scanning JARs is not really a good option in this environment. This is sort of a catch 22. Attributes not only solve a number of management issues, they introduce a host of new issues. Does this mean I consider them a failed experiment? No. I don't. I do see that if we are going to use these tools, we need a better way of using them in IDEs.
We can create a plugin when JSR 198 is done that would allow for this to happen, but what about now? We would need to write at least three plugins to get 90% of the users out there. I need JBuilder for work, but I really like IDEA for my own use. A large number of folks use Eclipse due to its attractive price tag.
With my GUIApp framework that I am developing, just getting it to run inside an IDE is a real chore. I have to use remote debugging just to see what is going on inside of it. Much of this is due to the magic with the classloader and attributes.
How would we simplify this conundrum? We could wait for JDK 1.5 and get what we really want as a language feature. But that doesn't help us now. How do we make Merlin easier to understand?
--
"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]
