On Fri, 16 Feb 2001, Geir Magnusson Jr. wrote:
> Jason van Zyl wrote:
> >
> > On Thu, 15 Feb 2001, Geir Magnusson Jr. wrote:
> > >
> > > My personal belief is that keeping things as simple as possible is the
> > > best thing to do.
> >
> > I agree with that, I don't think what I'm saying runs contrary
> > to the idea of simplicity.
>
> Not what you are saying as much as doing, as in this case, adding
> DBResourceLoader as is makes building Velocity require J2EE, doesn't
> it? Quite a requirement for a general template engine.
It's not required at all. You can check for the presence of any
resource with Ant, if J2EE is not around then don't compile
anything that's dependent on it. It's done with lots of projects:
Turbine checks for the presence of FreeMarker before compiling
any of the classes that depend on FreeMarker, and Tomcat doesn't
compile code like the CatalinaBlock unless Avalon is present.
That problem is easy to overcome, and that exact same problem
would happen anywhere you had a set of tools that not everyone
wanted to use.
> Honestly, DBResourceLoader is a troubling case for me to argue against
> like this, as it *is* very 'core' in some ways, so I will admit that I
> am not -1 on including it altogether, but really think that this a great
> time to stand back a little, and take a look at where we want to go. A
> little time here saves hours of pain later.
Where do you see the pain coming from? From including things
like DBResourceLoader in Velocity? I really don't think it's
this big of an issue to be waving a -1 around over the inclusion
of source file.
> I will commit DBResourceLoader to the whiteboard so people can start to
> play with it while we hash this out.
I thought we had. We have already had 3 +1 responses for keeping
the tools in Velocity.
> For example, if I am right that DBResouceLoader requires J2EE, maybe we
> build a J2EE 'extensions' package? Does that make sense?
Again, the simple Ant check.
> The
> JARResourceLoader would certainly go there as well, for example, or a
> VelocityServlet that's hip to webapp and alters the template path
> accordingly, leaving a plainer one for people using non-J2EE servlet
> runners.
>
> > > I also recognize, and have always, that these 'non-core' contributions
> > > are very important, and a place should be found for them, so they can
> > > grow and develop freely from the core template engine.
> >
> > I don't think an unimaginable number of tools are going to
> > pop up. I think it's more likely that certain patterns of usage
> > will emerge as people try to embed velocity in different
> > applications. I think what will happen is that a relatively
> > small set of tools will evolve and I think it's best that
> > we watch those tools.
>
> I agree 100% for fundamental tool support.
>
> > Even if we had a closely monitored sister project that
> > housed velocity-related tools where there might be 3
> > pluggable introspectors, 5 DBResourceLoaders, 4 sets
> > of tools for implementing the Pull Model I guarantee
> > that the typical question will be: "I was looking
> > over the tools at velocity-extras.org and I was
> > wondering what XXX tool most people are using?".
> >
> > I think the easiest answer to that inevitible question
> > is: "the one in the velocity repository". If the tool
> > is good then it must pass the scrutiny of the other
> > committers. If the tool is good then the author of
> > the tool gets to be a committer.
>
> Putting aside the DBResourceLoader for a moment, how about, "Any of the
> ones in the Velocity Tool project. All of them are well documented with
> useage examples. The group running that project really knows their
> stuff."
The Velocity Tool project? What's that?
> > The committer gauntlet so to speak. I think it would
> > be far less likely for someone to throw a tool at
> > the velocity committers then to a group at
> > velocity-extras.com. Even if it were you (geir)
> > looking after it. You are by far the most responsive
> > to queries from users, and the most committed of
> > the committers, and velocity wouldn't be here
> > without you, but I think you will have a hard
> > time managing the rats nest of code that will
> > get thrown your way in a sister project.
>
> At this point I think I should be committed. :)
>
> Please understand that my goal here is not creating some bag o' code (as
> I put it in christophs post)
Why do you think that's my goal?
> , but rather use the existance of Velocity
> as a lever to get another project in a closely related area started. I
> initially proposed a VelocityCentral.org/com a long time ago as I didn't
> quite understand how to get a project going, and figured that doing was
> easier than talking, thinking we could fold back into Jakarta as soon as
> something materialized if Jakarta was interested. I see now through my
> particiaption elsewhere in Jakarta-land that we can do it right here.
I don't agree at all with separating right now. My
primary objection is that I don't think it will work.
I think you are going to get the whole set of people
who will want to roll their own servlet framework and
none of those people will hesitate to rewrite some
tool they find to suit their own needs. So I think
you will find collaboration and cooperation
difficult with this bunch. Trying to make a general
UIManager say for 10 different servlet frameworks will
prove to be an unmanagable pain in the ass.
This project started with the intent on making a
templating engine for Turbine: plain and simple.
That it's turned out to be more widely used
as a general tool is great, that is cool. But
I personally don't want to be responsible for
the proliferation of 10 different servlet
frameworks. If people want to roll their own,
that's fine but I don't want to help them:
I want them to use Turbine. I'm totally biased
due to my participation in Turbine, so be it.
Separating a tools project will spark a raft
of servlet frameworks and again I personally don't
want that to happen. I agree that Turbine may
be a little rotund for the likes of some, and
some projects like Jetspeed have gone ahead
and done some of there own things because they
felt Turbine wasn't quite suited to their needs:
this is probably indicative of some deficiencies
in Turbine but that can be fixed.
I don't want to give people the opportunity to
redo Turbine, I want people to help fix Turbine.
Anyone wanting to use Velocity in the context
of servlets should be pushed strongly toward
Turbine. Turbine may have it's flaws but I see
it becoming the servlet framework that everyone
can use. I don't see the point in even trying
to encourage the production of another 'Turbine' and
it will happen if a servlet tools project is
started because everyone will roll their own.
You might say that this limits peoples choices, but
I say people sometimes don't know what's best for
them. Having a bunch of separate tools IMO is fairly
useless. When you start getting into an application
with any level of complexity it's the frameworks that
save you time. People will reach for Turbine or Struts
because all the components have been tested together
and there is a community supporting the infrastructure and
there is some methodology to building a complex
application. Struts has awesome docs and good example
apps, Turbine has the TDK which is the start of
something very useful for developers.
I think the development of complex applications should
be fairly transparent to a developer. With the TDK
you run a script and you get a working application.
And I think eventually you will be able to design
an entire Turbine application visually. Only with
many people developing apps with Turbine, and many
people looking at the code will the complexity
be managable. So I will go out of my way to keep
from losing any potential Turbine developers. I
would like to try and make Turbine attractive
to all the roll-my-own types. For those roll-my-own
types who want to get knee-deep-in-the-shit then
projects have to try and make the progression to
committer much easier.
We don't need more tools, or more frameworks we
need ingenious ways to attract developers who
want to get into the knitty gritty. Neato animated
UML diagrams that take a potential developer on
a guided tour of the source with colour coded
segments representing areas that need work.
It is sometimes easier to roll your own because
you don't have to deal with anyone else, but
you're not going to get a solid project doing
something like that.
I see some general utiltities as being useful across
projects like a connection pool, or XML configuration.
But when it comes to servlet tools, I say Turbine is
it and it should be promoted as the servlet solution
for people wishing to use a templating engine for
the view. I think making a set of servlet tools
would 1) Be hard because of all the roll-my-own
types you will attract and 2) Because it could
potentially detract from Turbine development. We
don't need any more servlet frameworks, we've
already got two!
> > People are hesitant to whip ad hoc code at
> > a set of committers and I think that's a good thing.
> > I think that 'hesitation' is a great way to diffuse
> > the potential duplication of code between any parties
> > who have different views on how something should
> > be implemented. If it were something like
> > velocity-free-for-all.org and people could just
> > upload stuff then you're going to end up
> > with a lot of potentially mediocre code. If
> > it is something you are going to try and manage
> > then I think it will be difficult without
> > the committer gauntlet. If you get 5 different
> > DBResourceLoaders thrown at you, are you going
> > to look at them all? If so that would be quite
> > a task, if not and they all go in then you
> > get questions on the mailing list asking which
> > DBResourceLoader to use.
>
> Gaaaaa! I think I made it clear before (previous post) that we don't
> have to have an offsite container for this.
>
> "I am totally +1 for
> lobbying and working towards the creation of another closely associated
> project to hold things like this - and would participate and work hard
> to make it succeed. "
>
> Ok. There - I don't feel so bad. I think that was clear :)
>
> I agree - the committer model used here is *very* effective. I just
> think that you can have a different set of committers. Yes, there will
> be overlap (you, Jason, are a prime candidate with your work in Turbine
> with the UIManager, Flux, etc, and your needs for the
> internationalization tools), but there will also be separation. My
> interests in performance and threadsafety in velocity don't necessarily
> translate to solid application toolsets. Not that I wouldn't want to
> help, but I just recognize them as distinct skill sets.
Like I said Turbine is the application toolset. I don't
want to see or promote any more.
> > In summary I think the set of tools to cover the
> > set of potential tasks for velocity apps will be relatively
> > small even the inumerable number of apps that might be developed,
> > and those tools should be watched over by committers
> > and stay in the velocity repository simply to reduce
> > the amount of slush that might get thrown our way.
> >
> > We can have different repositories to house the
> > core, and application portions of velocity. I just
> > think they should be part of velocity as a project.
> > The application portion of velocity may evolve to
> > a far greater size then I think it will, but I think
> > that is unlikely and I would say let that happen before
> > we think about making another project all together.
>
> It wouldn't be hard to separate.... Again, the DBResourceLoader
> *really* doesn't fall into the above class so much, but there is an
> issue there with J2EE stuff, I think.
No, it wouldn't. Lots of projects do it. No issue.
> I think a lot of good things would come out of a little separation.
>
> I think what is coming out of this is that there are multiple issues
> here. To me, I can summarize as :
>
> 1) DBResourceLoader is a good thing, it's more 'core' than 'tool'.
> Where to add and how to build is the question.
It's really not that complicated. I think with a couple rounds
of mail messages we could agree where to put it in the velocity
repository and modify the build to take into account any
conditional build requirements.
> 2) There are other tools that are attracted to Velocity becuase people
> working with Velocity in application building have good, proven things
> to share. The VelocityServlet is an excellent example of how real-life
> users extended it from purely application oriented activities (not low
> level bug or performance issues).
I think the Velocity servlet is a nice example but again promotes
the roll-my-own mentality which is bad.
> 3) We have already been bitten once by having 'utility' code in the core
> distribution that was not part of Velocity per se, and was being used by
> someone. When we removed it, they had a problem. I think we all want
> to avoid this from happening again.
I wouldn't really call that a crisis situation. That one was
my fault for leaving that code around but I don't think too
many people are using the now defunct object cache in
their web-controlled nuclear power plants.
> 4) I think that we have a great opportunity to get things going in the
> 'Shared Code Movement' here in Jakarta - we and Turbine have overlapping
> users with overlapping interests, and there must be a middle ground
> where an application tool project can live. That will give better
> visiblity to a large amount of tools that are hidden/buried, making
> Jakarta more useful for 'one stop shopping' for Java servlet and
> application developers. When the other 'shared code' project gets off
> the ground, we can reevaluate how we fit.
I think this is going too far with the code sharing vis-a-vis
a set of servlet tools. I don't want to see another servlet
framework. I don't see an application tool project, I see
Turbine. I am not in favour at all in starting anything that
will encourage someone to roll-my-own solution instead of
try Turbine. I think Turbine as a project and a solution
for servlet based development would benefit a vastly larger
number of people then an application tools project. That's
where I stand.
jvz.
