On Thu, 15 Feb 2001, Geir Magnusson Jr. wrote:
> Jason van Zyl wrote:
> >
> > On Thu, 15 Feb 2001, Geir Magnusson Jr. wrote:
> >
> > > That's great!
> > >
> > > We as a project need to work out what to do with non-core things like
> > > this - I am sure since it was useful to you, it will be useful to many
> > > others. (Yo, Paulo!)
> > >
> > > Anyway, there are a few other things floating around that are non-core/
> > > non-basic but need to be kept somewhere.
> > >
> > > If we set up a site / place for non-officially-supported contributions /
> > > accessories, would you be willing to commit to support it?
> >
> > If people are going to commit to supporting segments of
> > code, why do we necessarily have to go off-site to do this?
>
> 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.
> 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.
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.
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.
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.
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.
We can have different schedules for different portions
of velocity if it gets to that point but I don't
think it will. And if there are a good set of tools
that evolve then we can pull them out later, in the
meantime we can build separate jars for those tools
and people can use them separately if they want.
jvz.
> I think it's important to decouple the features, bugs, dependencies and
> release schedules of the core versus these extras. 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. We could push some of the current Vel stuff
> upwards, and maybe convince Turbine and other projects do move some of
> their utility code 'down'. :) It would make a more complete and
> accessible set of tools for servlet developers, and help stave off the
> 'Microsoft Office' monolithical model that is the logical conclusion of
> the bundling approach.
>
> > I think an org.apache.velocity.app package would do the
> > job. I don't think things like a DBResourceLoader, or
> > ServletResourceLoader are going to be abandoned and
> > I think it would be nice to have be in the velocity
>
> We already have an o.a.v.a package. A loader wouldn't belong in there
> anyway. I would bet the JARResourceLoader would be more generally used
> than a DBResourceLoader (the file system is *damn* good at handling
> files...), and in either case, yes, I will admit that these are in the
> gray area between pure app and pure tool, because of the tool
> dependencies.
>
> > CVS. We can definitely keep them in a separate JAR
> > file and keep them out of the core, but I think it would
> > be nice to keep them in CVS.
>
> CVS is a great thing! No doubt. Recommend it to everyone :)
>
> But glomming all into the same tree doesn't make a whole lot of sense as
> :
>
> 1) there may be different sets of developers / committers
> 2) There may be different goals. One is more application oriented, one
> is more tool oriented.
> 3) There may be different release schedules.
>
> > I think the idea for an VelocityCentral type site would
> > be good for things like apps made with Velocity, but
> > not the components to make the apps.
>
> The regular Jakarta Velocity site could be the 'Velocity Central' site
> for main pieces. Where it is hosted doesn't matter.
>
> > I think that it would be confusing and inconvenient
> > to have to grab resource loaders from somewhere other
> > then the velocity CVS, or a velocity dist. At least for things like a
> > resource loader: as a piece of code that doesn't
> > function apart from velocity. For other tools,
> > tools that might be used with any templating engine, or a general
> > servlet tool, I think it would be fine to keep them out
> > of velocity proper but I even think those could be
> > kept in velocity too.
>
> This is one of the reasons why I wanted to get away from WM. It was my
> impression that everytime something was touched, the
> FubiwabiToolLoaderBroker had a problem and had to be fixed. Or
> application tool Weebiwoogie needed feature X, and it was just bolted on
> to the core, breaking the Fubiwabi thingy that was just fixed the week
> before...
>
> This is what I really am worried about - scope creep. So we put the Foo
> class (this is not oriented towards any of the contributions or ideas...
> it's a general thing for me) Then the Foo class has some special needs
> for logging or connection pooling or... ok, strap that on, because you
> don't want the user to have sucky performance w/o the logger / pooler /
> magic configurator, then ...
>
> WM has been around for *years* and they haven't managed to get a defined
> release out there. Yes, it was pioneering, but still.
>
> Taking this train of thought to it's logical conclusion to me results in
> bundling the whole thing into a Turbine uberproject, rolling that into
> tomcat, and making one big J2EE jar :)
>
> geir
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity
>
