avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Clarifying Avalon and Metro
Date Wed, 11 Aug 2004 06:13:54 GMT
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.

  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message