However, concerns have risen over the legacy of the older avalon products, in particular avalon-fortress, avalon-ecm, and their respective dependencies. We wish to ensure the continued vitality, stability and availability of these products. There are many commercial and non-commercial efforts based around these products, and the new unified platform offers uncertainties and risk we are not prepared to accept.
As I expressed during our big ICQ pow-wow, I believe continued support of any product's client base is of utmost importance. And in the case of Fortress/ECM, I, too, want what is best for users of these products.
There has been discussion about, and invitations, to make that work within the scope of the avalon project itself, perhaps by partitioning the project into distinct subprojects, splitting avalon up into multiple new projects, or taking similar measures.
Like Hammett and Aaron and others, my preference is for the continued evolution/maintenance of these products to continue somehow under the Apache umbrella.
After many weeks of deliberation, we can only come to the conclusion that this is a way forward that is bound to fail. As has been shown over the last two years, avalon is not a project where such a setup can ever work productively. We feat that by going down this path, avalon as a community will suffer. This will negatively impact apache and all of avalon's users. We believe there's a better alternative.
We would like to propose that apache transfers maintenance of avalon-fortress and avalon-ecm over to us. We will endeavor to create a stable, solid, backwards- and forwards-compatible open source project where these containers and their community can prosper under the terms of the Apache License in peaceful co-existence with the avalon project.
I am also prepared to accept the fact that best thing for Fortress/ECM users and the healthy progression of Apache-Avalon is a transfer of the codebase eternal to Apache.
Without getting into further details as to what such a transfer would entail right away or how it should be executed, we would like to give you and the rest of the avalon community the opportunity to consider the pros and cons of this move, for apache, for avalon, and for our users, and then let us know if you're willing to co-operate with us on this issue to the ultimate benefit of all parties involved.
+1 from me given the items of interest addressed by you and Aaron in other posts in this thread.
Sasvata Chatterjee Peter Donald Berin Loritsch Leif Mortenson Michael Nash Peter Royal Leo Simons Mauro Talevi Carsten Ziegeler
I also would like to add that I too believe that it is an important action item of the Apache-Avalon group to provide a *straightforward* and *painless* migration path for Fortress/ECM users to the Merlin platform for those subset of users who desire to remain under the Apache umbrella. And the implementation of a Fortress facility for Merlin is reasonable vehicle for short-term migration. And while it certainly is of no direct concern or interest for the BOP, my hope is that some of the Fortress/ECM experts would find this work interesting and compelling. It would certainly go a long way towards maintaining a spirit of cooperation amongst the camps.
I also hope that some/all of the BOP will continue to be a part of the *stackable* component-container specification ideas that Niclas is spearheading, and that as these specifications are fleshed out, we can see a bright new day of interoperability first among the Avalon container siblings, and then branching out throughout the IoC community. If we (Avalon + BOP) can at least rally around Niclas' specification ideas, it is possible for us to establish a model of cooperation that might be contagious through the rest of the community. I hope that not only interest from Avalon and the BOP still exists in this domain (apart from the pragmatic maintenance of an existing product), but that real action will result from mere intellectual interest.
Cheers, Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
