I'd say the reason for the coexistence is the same as for a lot of components that coexist between Avalon and Commons.
Both projects have a similar mandate. Commons on a micro level, Avalon on a macro level. These different views seem to create a lot of internal disagreement between the two projects and a fair amount of politics. This leads to communication problems with both parties lacking awareness of what is in the other, and a lot of threads that continue as this one has [See Berin and Rodney's posts]. >From what little I've gleaned of Avalon [Yep, I'm as guilty as anyone of not having a clue what the other half is doing] they have been restructuring the components so that they are more independent of the entire framework. I'm not sure if they were from the beginning, but it seems to be that things are being refctored. This begs the question of: If Avalon is a macro view made up of micro components, and Commons is micro components, when will we hit a stage where we have a redundant micro-components project, and how should this be dealt with? My definition of macro vs micro is probably best expressed as giving someone a lego kit in a box versus giving someone lots of lego bricks. In the former there is a defined way to build the system, though you can play with it. In the latter it's entirely up to you. On Fri, 26 Apr 2002, Berin Loritsch wrote: > Steven Caswell wrote: > > I will certainly take a look at Avalon. So why is there a commons pool > > and commons dbcp if Avalon does the same and more? > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
