On Fri, 3 May 2002 21:27, Peter Donald wrote: > > My 2c: You guys don't know how cool it is what you got. If it ever hit > > you what the possibilities were, and all Apache projects were > > componentized as a first step, you would be overwhelmed with the > > potential, and so would the rest of Apache. Why isn't Struts Avalonized? > > etc. Duplication? It would be hard NOT to resolve the duplication > > problems if Apache was Avalonized, because when you got to duplicate > > functionality, there would be this elephant in the living room that had > > to be dealt with before moving on. So MUCH duplication. Hell, it's not > > duplication, it's out and out competition. My thing is better than your > > thing. > > Some of the duplication exists due to ignorance, some due to competition > and some because external projects were brought in that
err looks like I no finish my sentence :) Here it is... ... already had components. Some is due to differences in development stage. ie When certain projects were under development avalon was not stable or even beta so it was not really an option to use it. Other times a project is largely in maintanence mode or whatever and can't afford to refactor to outfit them Other people think all frameworks are a bad idea unless they are based on reflection and have no code imports etc or really want to use technology X (ie digester, log4j, stratum, PreferencesAPI etc). So it not only ego it is also a preference thing. I tend to have 50% of my code avalon-framework free and when it is "avalonized" I often do it as a component extending or containing the "raw" object. For example if you look at Extension project in excalibur. It is something to manage JDK1.3 "Optional Packages". It is completely independent of avalon-framework. However when I have integrated it into other systems I generally write a component that is "Avalonized" to that wraps the Extension code. And this is coming from someone who has 90% of his apps Avalonized ;) Keeping out framework from utility code just keeps the code flexible, low coupling and easy to to evolve in future. Sometimes it is complex enough to demand a component interface but sometimes you can get away with not avalonizing it. -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
