My general opinion is that it is easy to overthink and overengineer things like this. I am open to new approaches as long as they can demonstrate real value in real use cases. To state my biases: I am not a fan of Spring in general. It makes 'calling a constructor with args' into something difficult.
Grant starts to hit this on the head: there are many deployment scenarios and supporting one tends to make others trickier. I would rather not favor a deployment scenario over another, so have generally avoided trying to inject things like custom classloaders or DI or config files. My world view is that Mahout is foremost a library. It is a simple .jar you can embed. In my world I built one more layer around this, without disturbing the core library, to support the most likely deployment scenario as a web app. That seemed like a win. But it didn't make the code somehow web app-centric. I may be on a tangent now but I suppose my basic reaction is: skip this complexity and build this as an extensible library. As always I am open to being convinced otherwise. On Jun 18, 2009 12:26 AM, "Ted Dunning" <[email protected]> wrote: I have had very bad experiences with the complexity explosion that is common with Spring, but I very much like the philosophical underpinnings that drive it. I really don't see the need for a custom class loader. All we really have to do is inject a few classes here and there and they should be in the class path. It isn't unreasonable to imagine that this injection be done in spring style although the basic idea is so simple that it keeps getting re-implemented by umpteen different people. The real problem with spring is that if you let it in the door, people start using it for everything and there is a huge presumption that it is in charge of everything. Suddenly you have 5000 line XML configuration files and only 5% of your engineers can change them without cascading failures that are only detected at run-time and have *very* strange symptoms. A really different approach would be to use something like a scripting language as the glue. That removes the problem by moving the center of control and allowing the user to inject their implementations fairly simply. Similarly, if we just remove the idea that mahout is a command line program that must load the user's classes, and have the user write the command line side, then things are suddenly simple again because Mahout is just a library. On Wed, Jun 17, 2009 at 3:36 PM, Grant Ingersoll <[email protected]>wrote: > Ah, yeah, true. Not sure why that slipped my mind. Probably had Solr on > the brain. > > > On J...
