> -----Original Message----- > From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > As a non-member of the Avalon community, I've noticed that a rift opened > up there from far, far away. > > But as my primary project in the Jakarta Community (Turbine) considers > moving closer to Avalon, I'd still be very interested to get the view > from both sides. Could some of the Avalon folks maybe state in a few (!) > sentences, what is the issue over Avalon / Merlin and the rejected Metro > proposal?
What we have is a situation where *all* of the active committers within Avalon are committed to one platform, a single product strategy, a shared belief that we are onto some really good things, and a common interest in the development of these ideas, concepts, and products here at Apache. Way back the community voted on this subject and overwhelmingly endorsed a single product strategy, bringing to a definitive end a history of fragmented development communities within Avalon. The community has completely changed as a result, new faces everywhere, the content in Avalon that makes up the Merlin platform together with related build systems, development tools, supporting systems, etc. now represents around than 90% of the current codebase. Based on the experience of building, evolving and delivering successive versions of Merlin, we are now well into a stage where historic notions such as 'framework' are loosing relevance. In its place is a meta-model, slowly but surely taking over the role of container component contract compliance. In the version of Merlin used in Fulcrum we can do things like switch in new runtime systems, plugin new logging solutions, enable dynamic component reloading. But where we heading is the constant running, dynamically up-gradable component management platform. This requires not only pluging in of sub-systems, but also plugin support for the semantic model. At this point - there is no fixed framework. And at this point the role of Merlin in Avalon no longer makes a lot sense. In effect, where we are going is beyond Avalon. However, freedom to pursue these challenges is proving a challenge in and of itself. Members of the Board have opened up lines of communication and it's already clear that there is interest in enabling this, but also concerns from board members over existing users, and naturally - the reverent immutable framework. But all of this IMO is tainted with a historical bias - "damage limitation" seems to capture more attention then "innovation". There is a job ahead of us in turning this perception around. That's going to take patience and perseverance - but in the mean time, we are forging ahead on all fronts. Cheers, Steve. > Regards > Henning > > (I do understand that "moving out of the ASF" is a step that most > projects do only very, very reluctantly; not for technical reasons but > because a non-ASF project does not get the same (media and public) > exposure as an ASF project. (See also: Velocity vs. Freemarker). > > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire > Linux, Java, perl, Solaris -- Consulting, Training, Development > > "Fighting for one's political stand is an honorable action, but re- > fusing to acknowledge that there might be weaknesses in one's > position - in order to identify them so that they can be remedied - > is a large enough problem with the Open Source movement that it > deserves to be on this list of the top five problems." > --Michelle Levesque, "Fundamental Issues with > Open Source Software Development" > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
