I read all of the replies to this with great interest, and I think everyone has a point, which is very well the problem! :-) If both 'sides' are right, nothing will get accomplished as far as Jakarta using Avalon as a core. Personally I would like to see that happen, at least with the big projects like Struts, Tomcat (probably never happen but would be REALLY cool), velocity, turbine, etc.
Take a look at Struts, which I follow, and now they are running into issues with people wanting a pluggable extension. Right now everyone has to write their own subclass of the ActionServlet for validation, velocity, stxx, etc. Even we had to extend it for our product. Now imagine if that Servlet was avalonized(?), we could all build plugins for struts much easier. On the home-front, I started using Avalon for the basis of our scripting engine, and slowly over time convinced the boss that we should use Avalon throughout. I finally won him over and now I am refactoring our product to have one configuration file (previsouly had many property files), one central manager via Excalibur, and now our previous pluggable/swappable architecture is much cleaner and more flexible now. In short, I love it! On the Digester/Configuration issue, I ran into this as well when I started using Avalon. My boss was playing with digester for some stuff and I was using avalon's configuration stuff for my script engine. We finally settled on using Avalon, but I rationalized both of them by saying that Digester was a 'push' style mechanism, while avalon's was a more-or-less 'pull' style mechanism, and each has their place. Yes I know that the configuration object is supplied to the object, but that object pulls its own data out of it, hence the 'pull'. I personally don't see Digester as a configuration tool, but it can certainly be so and is for struts and others. Which leads me to my last topic, and that is that Avalon makes more sense to me if there are multiple ways of doing one thing and you want to be able to swap between them. Take logging for example. There is log4j, jdk1.4, etc. and Avalon provides the mechanism to exchange these underlying components without breaking anything, and to me THAT is what makes it most useful and great. For example our scripting engine is built using 'local' objects, but we might add the ability to have them remote, say as session beans, and of course I can swap that via the configuration. I realize I'm probably preaching to the choir here, but that is my .02; well maybe .03 :-) - Robert -----Original Message----- From: Jeff Turner [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Turner Sent: Thursday, May 02, 2002 5:27 AM To: Avalon Developers List Subject: [OT] Jakarta: keeping track of it all On Thu, May 02, 2002 at 09:13:12AM +0200, Leo Simons wrote: > > How about Commons Digester? The thing that parses Tomcat/Struts config > > files. It fits your description quite well. > > > > http://jakarta.apache.org/commons/digester/api/org/apache/commons/digest er/package-summary.html > > that's exactly the same concept completely worked out. And with good > docs. And in daily use already at jakarta. Cool beans! > > Commons needs some better advertising...can't remember ever seeing this > thing mentioned before...it is very cool when someone has already built > exactly what you need... It's disturbing to have all these "gosh I never knew" replies ;) Seems that Jakarta has far exceeded the point where one person can have a functional overview of all the subprojects. Past this point, code duplication inevitably occurs. Witness the Maven vs Centipede/Forrest flamefest on general@jakarta -- I reckon both camps were largely unaware of each other. <thinking out loud> It would be fun to apply some AI/semantic web solutions to the problem. Perhaps create a massive hyperlinked "knowledgebase" of projects and developers, where each entry has keywords associated with it, and hyperlinks between entries are assigned strengths, perhaps automatically updated by word frequencies in posts. Then create taxonomies to relate all the subjects.. then each project's website could have an automatically generated "Related projects and posts" section. Metadata, taxonomies and vocabularies. Watch those critters.. I reckon they'll become very important words in time ;) </thinking out loud> --Jeff > - Leo > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
