EverBank Financial Corp has placed a very strong strategical 
direction based on Merlin. It is imperitive for us that 
Merlin remain in a state of high quality and support, which 
it enjoys today from the community supporting it. It seems to 
me that as a top level project, Apache is better positioned 
to continue Merlin's success.

>I think this is the natural direction to go.  As Merlin has 
individuated,
>it has become something like a proof that there cannot be a 
standard
>Avalon container.  As such, it's a great idea to get the 
containers away
>from the framework.
>
>I'm committed to following Merlin's development, as sub- or 
top-level
>project.
>
>    Gary Shea
>
>>
>> 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&projec
ts=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&proje
cts=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: users-
[EMAIL PROTECTED]
>>
>>
>
>-------------------------------------------------------------
--------
>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]

Reply via email to