Hi Avaloners, Thanks a lot for the IRC log. It isn't easy to read but very informative. :-)
To make my point understandable I start with the 'Avalon story' of my company: Over two years ago I started to look for a server framework for a new Java project. On an earlier project I have developed a framework on my own but it was at a different company so I would have to do it all again. So I started to search for an open source project with that focus (EJBs seemed way too big). As I found Apache Avalon I stoped searching for two reasons: 1. I have searched already quite some time and it was the only thing that seemed to be ready for production. 2. I had very good experiences with other Java projects from Apache (log4j, ant, tomcat, ...). Professionalism and user orientation (versus sole academic concepts and experiments) seemed to be characteristic for Apache projects. We developed the beta version of the software with ECM according to the document 'Developing With Apache Avalon'. This was all fine and the software ran nicely at the cusomer site. Then ECM was suddenly deprecated (OK it took a few weeks) without any replacement. We had to deliver the 1.0 version in a few weeks and of course didn't want to have deprecated stuff already in the 1.0 (especially since the customer is getting the source code). So we migrated to Phoenix since it was the only stable and nondeprecated container left. Then we delivered the 1.0 version and started training for the customer. As the customer is getting the source code the training involved a lot of Phoenix stuff. And the customer was already asking quite a lot of nasty questions about Phoenix (haven't you used something else before, will it last, ...). Now Phoenix development has stopped. And we have to migrate a second time. But this time we will have *real* problems to explain it to the customer as he is very reluctant to any changes. So this time we have to make sure that it is really the last time (or we will loose the customer) and we have to do it again on our own costs of course! To be sure that a third switch isn't necessary is impossible with more than one product in the same project. So we don't mind what container will stay at the and of the discussion process. We only need one thing: 1 Website, 1 Container, 1 Project, 1 Mailinglist, 1 PRODUCT The main reason for choosing Avalon was that I assumed that it would be a quite professional, straight forward user oriented project that wants to benefit the Java world. How very wrong I was. Now projects like the springframework would fit much better to Apache and Avalon would fit much better to sourceforge. I am not interested in the academic discussions what esoteric feature one container supports that another container doesn't. Any container will be fine for us! For us it is only important that I can count on the product being 'stable' (API-wise) for the next five to ten to twenty years (that is the planning horizont of our customer: the software that our will replace is about 18 years old). In the long run special features of a container are unimportant compared to the number of existing compnents and users. It is just like programming languages: - the features of the language don't really matter - the libraries you get with it really count since they determine the development costs and the time to market. Maybe it would be best to have a maximum of 3 developers who are allowed to discuss and commit any changes to containers. Everybody else could do components, tests, documentation. What a wonderful project this would be within a few months! (of course such a rule is impossible! :-) I hope you are able to come up with a solution before all users are gone and my project is ruined. With best regards, Ole __________________________ Ernst Basler + Partner GmbH Ole Bulbuk Tuchmacherstra�e 47 DE-14482 Potsdam +49 331 74 75 9 0 (Zentrale) +49 331 74 75 9 60 (Direkt) +49 331 74 75 9 90 (Fax) mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
