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.
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.
I will commit DBResourceLoader to the whiteboard so people can start to
play with it while we hash this out.
For example, if I am right that DBResouceLoader requires J2EE, maybe we
build a J2EE 'extensions' package? Does that make sense? 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 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), 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.
> 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.
> 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.
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.
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).
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.
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.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
