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, and
is 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
