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 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 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
