On Wednesday 11 August 2004 03:19, Farr, Aaron wrote: > Concerns > ======== > I'm sure there will be a few. Despite framework development having often > been rocky territory, I believe the elimination of container development > from Avalon will actually help the situation. So this isn't a big concern > on my list.
Framework is a funky piece of code, but since the majority of the world (some being active Avaloners) has concluded that the strong tie-in to any framework is a bad thing and should be abolished altogether, AF4 finds itself in a strange position. OTOH, the proposed alternative is still 'framework based', namely JavaBeans, but JavaBeans have a much wider acceptance and a lower common denominator than for instance AF4. IMHO, I think this (settling with JavaBeans only) is generally a step backwards, and not the long-term solution for producivity gains, only manifesting more 'invention in-house' than necessary. I think Avalon's future with AF4 is not a technical issue, it is not a matter of 'which way is better'. It is a political and, more importantly, an emotional issue. People who committed to AF4 are pissed-off that this 'promise' turned sour, and they are stuck, and we can see the backlash to such sentiment in form of Type2 and Type3 initiatives. Avalon failed to deliver on its promise, IMHO mostly due to under-specification and leaving too much up to the container and directly creating the component's and application's dependencies on the container instead of the Framework. This damage is done, and the Java world may never get over with it. J2EE is struggling with the same issue, but at a more gigantic scale. They are holding up mainly due to a massively over-engineered specification, yet applications tend to become container-dependent, and we may see a backlash in this area at some point or the other later. I think Framework will be phased out of most products, either completely or used as a wrapper to still work with the container of choice. Containers and platforms that can work without AF will become the choice, and AF will fall into the history books and marked 'legacy'. It is a dead end, due to its own history. LogKit's future is pretty much sealed too, not so much due to any 'history', just that Log4J has taken over the market. Log4J just needs some engineering in the IoC and classloading area, and there is no need for a LogKit any more. So what should Avalon do? > As for component development, I believe there is a need for a component > repository/library in the IoC world but I'm not sure if Avalon is the place > for it. I agree, and for the same reasons you list, I doubt that ASF can be the repository. BUT, it could provide the indexing tools and infrastructure for it. Some of this would intersect with the recent developments at Gump, which calls for descriptions and indexing of 'projects', and perhaps Avalon should be working towards such goals. Having another "commons" is probably not the greatest of ideas, and I doubt it will be any more successful than jakarta-commons, which have maintenance problems. Perhaps Avalon should take over the entire jakarta-commons codebase, to ease the burden on the Jakarta PMC... > Anyway, those are my thoughts about the situation. Perhaps I answered > Noel's questions, perhaps I did not. Thoughts and feedback welcome. Noel, the direct implications of a ratification of the Metro TLP proposal is that Avalon will be free from "container wars", which even manage to exist with a single container in Avalon. My personal belief is that Avalon will go to Avalon, the final resting place. Not for technical reasons, maybe not even for community issues, but for historical ones. If we are setting out on brand new adventures, and need to be fighting the public opinion about the 'have beens', the road ahead will be ever so tough. I think it is better in such case to start afresh. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
