I also want to echo the subtle comment which Dave made about seeing a prototype of a Roller backend wired via Spring. The fact is that it's easy to prefer Spring over Guice in a discussion, but until someone puts up some code to actually provide a functional Spring backend then this discussion is somewhat academic. Using Spring DI has been discussed on this list numerous times in the past and it has always ended the same way, without any actual code, so I'm sorry to say it but unless one of the Spring fans steps up to the plate and offers some real code then there is really only one option to vote for.
-- Allen Sam Neth wrote:
I'm pretty new to Roller; I deployed 3.1 in production on Tomcat 6 / Oracle 10 a few days after it was released, after a week of tweaking with 3.0. I've given some consideration to contributing to the project, and I'm running with a tweak that I feel shouldn't have required patching a Roller class, so I subscribed to the dev list to see what's going on.I've been watching this discussion with great interest. One of my first reactions to the Roller codebase was that it was a shame it wasn't wired up with DI, so I was pleased to see this discussion only days later. I very recently left a job where for a year I led the development of a system that makes heavy use of Spring; not just for DI but other features as well. It took a while to really get my head around what Spring could do and why it's a good thing, but I came to have a deep appreciation for it. Having been through that, I can understand why people new to Spring might reject it prematurely, as it seems several people on this list have done, and as Bob Lee seems to have done before conceiving Guice. That seems to be the pattern; people who have used Spring favor using Spring, people have not think it's too hard. Spring has a lot to offer beyond DI too; I'd rather see Roller 4 using Spring MVC than Struts 2, but that's for another day. On the other hand, there is a widespread presumption that anything that comes out of Google is light from the heavens. There are things about Guice I really find distasteful, not least the fact the whole thing is based on mandatory use of framework-specific annotations, and the resulting half-baked approach to the inevitable boundary with non-Guice modules. I freely admit my relative ignorance about Guice, but I did try to look at it with an open mind, and I find it to be clever but misguided.I think a more informed evaluation is warranted. I wish I had time to do a Spring prototype of Roller, but I don't. Ultimately though, this may be a matter of taste. Some people think annotations are the cure for all ills. Some think they can be a step backwards.Dave wrote:On 5/20/07, Anil Gangolli <[EMAIL PROTECTED]> wrote:I'm really happy that we are playing in this direction, because I think adopting the DI model, if we really adopt it fundamentally, will tend to improve our modularity and clarify dependencies.On the choice of Guice, I have concerns. From my perspective Spring is more mature, well-documented and tested, has a more open contribution model, andis in wider use amongst a broader community. Plus we have at least two committers that are using it in other settings.I've been interested in Spring and have looked at it a number of times in the past. I even put down my own money for a copy of Raible's Spring Live book and read the IOC relevant chapters. It's a good book, but Spring never clicked for me. It just seems too complex -- and I'm just talking about IOC, not the giant mountain of other Spring APIs. Guice, on the other hand is simple and easy. It took me no time at all to figure out -- no books or extra docs necessary. It's my understanding that Guice now powers Google Adwords. You'd be hard pressed to find a more massively distributed, scalable, etc. Java app out there. So, I'm not particularly worried about Guice maturity and testing. What do you mean by open contribution model? At JavaOne I spoke with the COO of Interface21, the now venture-backed start-up that controls Spring. He told me that Spring does not accept external committers and has no plans to do so. Is that true? And if so, how is that an open contribution model?Guice? They even let the bile blogger in. How much more open can you get ;-)I hope I'm not sounding too harsh here. Don't forget, I'm just one committer here with one vote like the rest. If some other committer wants to create a roller_spring branch and show us how to wire everything up with Spring IOC, that's great. I promise to take a close and fair-minded look at that work. But at this point, I'm personally more interested in promoting Guice.I understand some of the aversion to the XML configuration. Still XML can be readily manipulated both manually and automatically during installation;I hope we won't be asking users to modify distributed code in order, for example, to add plugins or to swap a rendering model implementation.Definitely not. Plugin writers should never have to modify Roller code. - Dave
