Jason van Zyl wrote:
> > 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.
> [SNIP]
If you read on later, what I was thinking is that we could setup a J2EE
support package with tools that are relevant for J2EE - so you could
have a build target that either adds the J2EE stuff, or makes a separate
jar. Thats all.
>
> > 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 am not "waving a -1". "I am not -1 on including it altogether" meant
that I am not against (-1 == against) including it, but I think we
should figure out where things like this should go rather than just
piling them in. I don't think I at any point rejected the
DBResourceLoader, but rather started this thread trying to explore the
idea of having alternate places for things.
> > 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.
Let me count :
- I *assume* you are +1 but you didn't really vote.
- Daniel is +1 on putting in o.a.v.app.
- Jon agrees with the idea that it would be confusing to grab resource
loaders from 'elswhere' and further notes that Turbine hasn't been
released.
- Christoph approves but is willing to discuss organizational issues.
- Theo appears to agree that organization is worth discussing.
- I am interested in discussion of organization, if that's not obvious
:)
So to be technical, there was only one +1 from Daniel, and the rest were
either implied, or recoginition that maybe we should talk about
structure.
>[SNIP]
> > >
> > > 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?
An invention for the sake of demonstration. Come on...
>[SNIP]
> > 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?
My statement didn't imply anything about you or your goal. What my
statement was addressing was that it appears that despite all
explinations from me to the contrary, it is believed that I want
something other than a committer-led project to handle this stuff. I
*explained* the intent behind the old 'VelocityCentral' idea, and how I
understand *now* how to go about trying to do something here in Jakarta.
> > , 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.
Ok. Noted - I don't think that the servlet framework fear is likely, as
the charter of the project could be very clear on that, and two,
involvement of people from both Velocity and Turbine would prevent
that.
Futher, if we don't have a separate project,I think it might be worth
discussion of the idea of a separation in the source tree.
> 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.
That's fine, and it's a credit that this wasn't sucked into Turbine, and
is free of Turbine dependency, making it available for all to use. It's
a great contribution.
> 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 think that could be controlled.
>
> 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.
I don't think that this is about Turbine. I only brought Turbine in
because of the close ties of the projects and project participants. I
have no interest in clouding the waters there either, btw.
First, if a tool project threatens Turbine, which I don't think it will,
then that is something Turbine will have to address *anyway*. Second, a
strict charter for a project like this would keep that from happening,
and if there was enough developer interest in another framework, a group
could easily propose to the PMC. Finally, this isn't about frameworks.
There are more pieces than just frameworks (such as context tools)
I recognize that Turbine is the framework in this, and Velocity is the
template engine. I don't drift from that orthodoxy. I just see a space
in between that we have code and interested, experienced developers to
help fill.
To be painfully explicit, I see Jakarta supplying a complete top to
bottom 'solution' (ugh, sorry) :
Tomcat (or other servlet runner)
Turbine (or not)
Tools (or not)
Velocity (what else is there? ;)
where a user can use any part(s) that they want. Right now, we don't
have the middle 'Tools' layer, and I believe that it's needed.
> You might say that this limits peoples choices, but
> I say people sometimes don't know what's best for
> them.
I certainly don't. :)
> 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.
And a tool project might help solve that. It could be run by people who
have experience and interest in tools for use with Velocity, tools for
use with Servlets, different ideas for Servlets, or pieces that work in
framworks.
>
> 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!
There are many ideas in here, I can't say "I agree" or "I disagree" to
the whole thing. I think we have the same goal in mind, but see subtle
variations in the path.
What I am thinking about, and apparently having a whale of a problem
communicating, is that between Turbine and Velocity there is a space.
And I believe that the two projects have enough code and developers to
fill that space.
I personally realize that in the grand scheme, Velocity is a tiny part
of the Servlet development food chain, but I take tremendous pride in
working on it, maybe because of its independence. I think that there
would be a positive motivational effect with a tool project - bringing
the tool developers front and center like that in a project. The tool
layer is an important part of servlet development, and is a space for
innovation and growth like any other part. We are still early in the
'Age of Servlets'.
> > 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.
So what do we do? Reject anything that isn't as core as
DBResourceLoader and tell people to go to Turbine?
>[SNIP]
> >
> > 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.
Well, it appears that no one is interested in exploring this much deeper
than we have, so I guess I am more or less forced to agree.
> > 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.
Sorry - people are going to do what they want. Either have existing
applications which VelocityServlet helps with to get Velocity used, or
have restrictions which prevent something like Turbine being used, etc.
You can encourage, promote, etc, but at the end of the day, people have
their own ideas.
> > 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.
I am not sure I described it as a 'crisis'. It was meant to illustrate
that people are inquisitive and do look around in the source tree, and
use useful things. If turbine uses it, that would be cool tool to pull
out for general use, right?
> > 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.
That's clear.
> jvz.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
