Hello everyone, first of all I apologize for my bad English. Now, that is how I see things:
>Merlin is so much more than what the founders of Avalon anticipated, and the >Merlin committer crew (esp. myself, Steve, Alex, and Timmothy) feels that >there are an unnecessary restrictions on how we can evolve Merlin, without >creating fear at the other projects depending on Avalon. In my opinion it will be good for Merlin to get rid of restrictions and let Merlin evolve freely. How knows what important discoveries are waiting to be found out there. The impact of the evolution of Merlin on Avalon (and the consequences of that impact on Avalon dependent projects) is another issue that I am not able to tackle, to be honest. Having said that, I have the feeling that Merlin is becomming a platform for component assembly (and deployment?), regardless of the framework (Avalon, etc...) on which component parts are designed and built. Cheers. Roberto. > -----Mensaje original----- > De: Niclas Hedhman [SMTP:[EMAIL PROTECTED] > Enviado el: jueves, 22 de julio de 2004 3:43 > Para: Avalon Users > Asunto: A Merlin Top Level Project > > > Hi everyone. > > This mail is directed to EVERY USER of Merlin, if you just starting out, half > way ahead and experienced, _please_ read and respond. > > == Abstract == > Avalon has yet again been under fire for making too much changes to the Avalon > Legacy (read Framework, site and documentation), what constitutes compatible > changes and how these changes are perceived by the Avalon-dependees, such as > Excalibur, Cocoon, James and Loom. The aftermath of this last storm, makes > _me_ believe that Avalon should NOT be the home of Merlin, and I am lobbying > for the support of a Merlin Top Level Project. > > == Purpose == > Merlin is so much more than what the founders of Avalon anticipated, and the > Merlin committer crew (esp. myself, Steve, Alex, and Timmothy) feels that > there are an unnecessary restrictions on how we can evolve Merlin, without > creating fear at the other projects depending on Avalon. > > We think it is better for Merlin to be a user of Avalon Framework, like > Excalibur, Loom, James and Cocoon are, without any special privileges or > obligations. > > The Merlin committers wants to forge ahead with a vision of a serious > alternative/compliment to J2EE, where component oriented programming finally > gets to its full potential as an efficiency enabler. > > We want to send a clear message that Merlin is not a 'project' shuffled into a > backyard called Avalon, but that it is a serious _product_, on par with other > ambitious products in ASF like Geronimo, Cocoon and Eve. Avalon have lately > had as many or more web site visitors[1] than high profile projects like > Struts, Tomcat and Ant. This is a sign that there is a strong interest out > there, and that we need to channel this interest into a stronger community. > > I think that a Merlin Top Level Project is due, the technology and community > is mature, the increased visibility will spark even higher interests, and > that we can accelerate the development of the platform better without the > concerns of Avalon legacy. > > The Merlin committer crew is also determined to increase the frequency of > releases, especially on facilities and generic components. Less of our energy > will be spent on the 'infamous in-fightings of Avalon', and we can serve the > community better. > > > == Mitigation of Consequence to Users == > This will not be a pain-free exercise. > If we are granted "The Apache Merlin project" (http://merlin.apache.org), we > will most probably be required to change the codebase package names. > > However, I hope that we will be able to bridge the inconvenience for the > "Facilities Users", who would have wrong classnames for the facility > declaration, so that Merlin will explicitly recognize both namespaces for > > some time, and generate a deprecation warning. > > Native normal components would work as without change. > > Blocks (aggregated components, i.e. block.xml files) should also work without > change. > > Applications that embedds Merlin is the only major area, where we can't > provide a smooth transition. I.e. import statements will have to change, but > with modern IDEs (alt. some script files), the work would be fairly straight > forward and quick. > > > == YOUR action is required == > > I NEED you to respond to this mail. If you like the sound of this idea, just > send a mail to the list saying exactly that. If you think this is not a good > idea, please express that too, to this list. This is not a vote, just a call > for support. > > The more support I can rally from the users, the more likely the proposal will > be viewed positively by the ASF Board, whio ultimately decides on this. > > > Cheers > Niclas > > [1] > Daily stats (90 days): > http://reverycodes.com/apache/stats/stats.pl?type=projects&day=&month=&year=&interval=day&periods=90&projects=ant&projects=avalon&projects=struts&projects=tomcat > > Monthly stats (6 months): > http://reverycodes.com/apache/stats/stats.pl?type=projects&day=&month=&year=&interval=month&periods=6&projects=ant&projects=avalon&projects=struts&projects=tomcat > > > -- > +------//-------------------+ > / http://www.bali.ac / > / http://niclas.hedhman.org / > +------//-------------------+ > > > --------------------------------------------------------------------- > 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]
