You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Geir Magnusson Jr <ge...@4quarters.com> on 2004/06/25 16:33:18 UTC
Re: More Veltag questions...
Could we get this as a patch to what's in CVS ? :)
On Apr 16, 2004, at 3:05 PM, Nathan Bubna wrote:
> Gupta, Arindam said:
>> Received the following errors while compiling:
> ...
>> D:\VelocitySource\jakarta-
>> velocity\contrib\temporary\veltag\src\java\org
>> \apache\taglibs\velocity\JSPContext.java:41: cannot resolve symbol
>> [javac] symbol : constructor ChainedContext
>> (<nulltype>,javax.servlet.ServletRequest,javax.servlet.ServletResponse
>> ,j
>> avax.servlet.ServletContext)
>> [javac] location: class
>> org.apache.velocity.tools.view.context.ChainedContext
>> [javac] super(null,
>> [javac] ^
>
> oh, yeah. you'll have to cast the ServletRequest and ServletResponse
> to
> HttpServletRequest and HttpServletResponse.
>
>> D:\VelocitySource\jakarta-
>> velocity\contrib\temporary\veltag\src\java\org
>> \apache\taglibs\velocity\VelocityTag.java:185: cannot resolve symbol
>> [javac] symbol : variable TOOLBOX_KEY
> ...
>
> add this to VelocityTag:
>
> /**
> * Key used to access the toolbox configuration file path from the
> * Servlet or webapp init parameters
> ("org.apache.velocity.toolbox").
> */
> protected static final String TOOLBOX_KEY =
> "org.apache.velocity.toolbox";
>
>
>> I had to add a couple of import statements in the VelocityTag.java and
>> fix a semi-colon.
>
> yeah, like i said, i threw it together "hastily" (i.e. in about 10
> minutes)
> and hadn't even tried compiling yet. sorry. :-/
>
>> I will send out the final code once I have tested it.
> ...
>
> that'd be great. thanks!
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Will Glass-Husain <wg...@forio.com>.
To be honest, I've always thought the primary reason the "Tools" and
"Velocity Core" are separate had to do with access control, release
schedule, and quality control.
Geir and the few other Velocity committers have kept tight control over the
source control for Velocity, with an articulated goal of keeping the core
language simple and backwards compatible. (there's downsides to this, of
course, such as a multi-year release cycle). Breaking out the tools
project allowed Nathan and others to have flexibility over creating updates
and issuing releases.
So, I suggest three criteria to decide whether or not Anakia/Texen should be
part of the "core".
--> Are there people interested in maintaining & upgrading the code (outside
of the core committers)? This is critical.
--> Does it live outside of the strict quality control umbrella of Velocity
core (e.g. keep the language clean and backwards compatible at all costs)
--> Does it require a release schedule different than Velocity?
It's not clear to me that "logical organization" matters so much, as opposed
to the above bullets.
WILL
----- Original Message -----
From: "Tim Colson" <tc...@cisco.com>
To: "'Velocity Developers List'" <ve...@jakarta.apache.org>
Sent: Tuesday, June 29, 2004 8:09 AM
Subject: RE: Velocity Core and Tools separation
> Broken collarbone as of Sunday, so I'll be quick/short... typing is mosly
> 1-handed at the moment.
>
> Nathan said these things:
> > i agree that Anakia/Texen probably ought to be
> > moved out of the core, but i just don't want them in VelocityTools. :)
>
> > c'mon. i'm not saying it's not a tool in the general sense of
> > the term. if you can explain to me how Anakia is similar in
> > function/use/purpose to the contents of the VelocityTools project, i'll
> listen.
>
> > i still haven't heard you justify their inclusion with
> > something better than the vague semantics of the word "tool."
> ------
> I'm just saying that the website already lumps those "other things" into a
> Tools category, but in the distro they are in CORE-- not Tools, not
> VelocityTools, not "Other things Nathan doesn't want in Tools because it's
> not a "Velocity Tool"... well, or it's not a Servlet which is okay...
> certainly not a "tool" like "Struts Message Tool" is a "tool", but it can
> use a toolbox, so it's okay... especially cuz' Nathan likes servlets.".
> <grin>
>
> I don't see how a half dozen Anakia classes will ever live on their own as
> jakarta-velocity-anakia. And in 3 years, I haven't seen those other things
> change much at all. I'd be willing to help move/maintain (fwiw) those
other
> things as sub-areas of the jakarta-velocity-tools project out of the
desire
> just to get them out of core, and make things seem a bit more logical.
>
> The broad semantics of the word "tool" is exactly the reason why I can
> easily see these things which are not CORE going into Velocity Tools,
that
> and the indisputable fact that somebody at some time filed them into a
> "Tools" category on the website, so I'm not the first idiot to come up
with
> the idea.
>
> But I'm not interested in this little argument... so that stuff will
> probably live on cluttering up the core, because no better alternative has
> been given to putting them into jakarta-velocity-tools.
>
> Ah well, I'm going to be forced to use JSTL instead of Velocity soon
anyhow.
> ;-)
>
> Cheers,
> Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Dave Newton <da...@solaraccess.com>.
On Tue, 29 Jun 2004 13:12:25 -0700 "Will Glass-Husain" <wg...@forio.com> wrote:
> Yeah, bad news about the collarbone.
I thought we'd decided the fake boobs would help cushion a terminal endo.
(Yeah, we know it wasn't you ;)
> The only downside (which I'm hitting in an app right now), is that it's web only.
There is a project whose name escapes me that uses a JSP-like (identical?) syntax
as a template engine, and I can't surf to find it right now, so I'll just shut up.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Will Glass-Husain <wg...@forio.com>.
Yeah, bad news about the collarbone. Guess that must kill the biking for a
while. (I'm feeling a little abashed in that I wrote my email before my
morning coffee, didn't have the attention-span for social niceties).
I kinda like JSTL, by the way. (heresy here, I know). With a good MVC
framework it makes the JSP pages very clean, and looks nice in DreamWeaver.
In JSP 2.0 it reminds me of Velocity. The only downside (which I'm hitting
in an app right now), is that it's web only. (can't reuse a JSP/JSTL page
as an email template, for example).
WILL
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Tuesday, June 29, 2004 10:37 AM
Subject: Re: Velocity Core and Tools separation
> Tim Colson said:
> > Broken collarbone as of Sunday, so I'll be quick/short... typing is
mosly
> > 1-handed at the moment.
>
> sorry to hear that. :(
>
> > Nathan said these things:
> > > i agree that Anakia/Texen probably ought to be
> > > moved out of the core, but i just don't want them in VelocityTools. :)
> >
> > > c'mon. i'm not saying it's not a tool in the general sense of
> > > the term. if you can explain to me how Anakia is similar in
> > > function/use/purpose to the contents of the VelocityTools project,
i'll
> > listen.
> >
> > > i still haven't heard you justify their inclusion with
> > > something better than the vague semantics of the word "tool."
> > ------
> > I'm just saying that the website already lumps those "other things" into
a
> > Tools category, but in the distro they are in CORE
> ...
>
> yeah, but the website isn't much of an authority figure as far as i'm
> concerned. that category could just as easily have been called "Related
> Projects." where would your argument be then?
>
> > I don't see how a half dozen Anakia classes will ever live on their own
as
> > jakarta-velocity-anakia. And in 3 years, I haven't seen those other
things
> > change much at all. I'd be willing to help move/maintain (fwiw) those
other
> > things as sub-areas of the jakarta-velocity-tools project out of the
desire
> > just to get them out of core, and make things seem a bit more logical.
>
> if you want to get them out of the core, why aren't you arguing for them
to be
> put into the dvsl sub-project? certainly they have more in common
there...
>
> > The broad semantics of the word "tool" is exactly the reason why I can
> > easily see these things which are not CORE going into Velocity Tools,
>
> oh yeah, that's right, because DVSL doesn't have the word "tool" in it's
name.
> sheesh. all this just makes me want to change the name of the
VelocityTools
> project. what if we called it "firebird"? ;)
>
> > that and the indisputable fact that somebody at some time filed them
into a
> > "Tools" category on the website, so I'm not the first idiot to come up
with
> > the idea.
>
> AFAIK, the website (which doesn't get to vote in this matter) had a
"Tools"
> category with things like Anakia/Texen/Veltag/etc in it before there ever
was
> a VelocityTools/Struts project. They were listed as "tools" on their own
> before their ever was a new "tools" subproject to integrate velocity with
> struts. in other words, the "tools" category on the main website is has
never
> been parallel or equated to the unfortunately named VelocityTools
subproject.
> So it is a non sequitur to conclude from this "indisputable fact" that
> Anakia/Texen should be in the VelocityTools project. And also note that
if
> such a conclusion were reasonable, it would also then be reasonable to put
> every other bullet item in that "Tools" category on the website into the
> VelocityTools project. and i hope you at least agree that that would be a
bad
> idea.
>
> > But I'm not interested in this little argument... so that stuff will
> > probably live on cluttering up the core, because no better alternative
has
> > been given to putting them into jakarta-velocity-tools.
>
> i really don't see the problem with putting them in their own subproject.
> that's better than just having them "clutter up" another project instead.
i
> don't care how few or many files are in a project. but it's not really my
> call.
>
> > Ah well, I'm going to be forced to use JSTL instead of Velocity soon
anyhow.
> > ;-)
>
> bummer.
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Broken collarbone as of Sunday, so I'll be quick/short... typing is mosly
> 1-handed at the moment.
sorry to hear that. :(
> Nathan said these things:
> > i agree that Anakia/Texen probably ought to be
> > moved out of the core, but i just don't want them in VelocityTools. :)
>
> > c'mon. i'm not saying it's not a tool in the general sense of
> > the term. if you can explain to me how Anakia is similar in
> > function/use/purpose to the contents of the VelocityTools project, i'll
> listen.
>
> > i still haven't heard you justify their inclusion with
> > something better than the vague semantics of the word "tool."
> ------
> I'm just saying that the website already lumps those "other things" into a
> Tools category, but in the distro they are in CORE
...
yeah, but the website isn't much of an authority figure as far as i'm
concerned. that category could just as easily have been called "Related
Projects." where would your argument be then?
> I don't see how a half dozen Anakia classes will ever live on their own as
> jakarta-velocity-anakia. And in 3 years, I haven't seen those other things
> change much at all. I'd be willing to help move/maintain (fwiw) those other
> things as sub-areas of the jakarta-velocity-tools project out of the desire
> just to get them out of core, and make things seem a bit more logical.
if you want to get them out of the core, why aren't you arguing for them to be
put into the dvsl sub-project? certainly they have more in common there...
> The broad semantics of the word "tool" is exactly the reason why I can
> easily see these things which are not CORE going into Velocity Tools,
oh yeah, that's right, because DVSL doesn't have the word "tool" in it's name.
sheesh. all this just makes me want to change the name of the VelocityTools
project. what if we called it "firebird"? ;)
> that and the indisputable fact that somebody at some time filed them into a
> "Tools" category on the website, so I'm not the first idiot to come up with
> the idea.
AFAIK, the website (which doesn't get to vote in this matter) had a "Tools"
category with things like Anakia/Texen/Veltag/etc in it before there ever was
a VelocityTools/Struts project. They were listed as "tools" on their own
before their ever was a new "tools" subproject to integrate velocity with
struts. in other words, the "tools" category on the main website is has never
been parallel or equated to the unfortunately named VelocityTools subproject.
So it is a non sequitur to conclude from this "indisputable fact" that
Anakia/Texen should be in the VelocityTools project. And also note that if
such a conclusion were reasonable, it would also then be reasonable to put
every other bullet item in that "Tools" category on the website into the
VelocityTools project. and i hope you at least agree that that would be a bad
idea.
> But I'm not interested in this little argument... so that stuff will
> probably live on cluttering up the core, because no better alternative has
> been given to putting them into jakarta-velocity-tools.
i really don't see the problem with putting them in their own subproject.
that's better than just having them "clutter up" another project instead. i
don't care how few or many files are in a project. but it's not really my
call.
> Ah well, I'm going to be forced to use JSTL instead of Velocity soon anyhow.
> ;-)
bummer.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Velocity Core and Tools separation
Posted by Tim Colson <tc...@cisco.com>.
Broken collarbone as of Sunday, so I'll be quick/short... typing is mosly
1-handed at the moment.
Nathan said these things:
> i agree that Anakia/Texen probably ought to be
> moved out of the core, but i just don't want them in VelocityTools. :)
> c'mon. i'm not saying it's not a tool in the general sense of
> the term. if you can explain to me how Anakia is similar in
> function/use/purpose to the contents of the VelocityTools project, i'll
listen.
> i still haven't heard you justify their inclusion with
> something better than the vague semantics of the word "tool."
------
I'm just saying that the website already lumps those "other things" into a
Tools category, but in the distro they are in CORE-- not Tools, not
VelocityTools, not "Other things Nathan doesn't want in Tools because it's
not a "Velocity Tool"... well, or it's not a Servlet which is okay...
certainly not a "tool" like "Struts Message Tool" is a "tool", but it can
use a toolbox, so it's okay... especially cuz' Nathan likes servlets.".
<grin>
I don't see how a half dozen Anakia classes will ever live on their own as
jakarta-velocity-anakia. And in 3 years, I haven't seen those other things
change much at all. I'd be willing to help move/maintain (fwiw) those other
things as sub-areas of the jakarta-velocity-tools project out of the desire
just to get them out of core, and make things seem a bit more logical.
The broad semantics of the word "tool" is exactly the reason why I can
easily see these things which are not CORE going into Velocity Tools, that
and the indisputable fact that somebody at some time filed them into a
"Tools" category on the website, so I'm not the first idiot to come up with
the idea.
But I'm not interested in this little argument... so that stuff will
probably live on cluttering up the core, because no better alternative has
been given to putting them into jakarta-velocity-tools.
Ah well, I'm going to be forced to use JSTL instead of Velocity soon anyhow.
;-)
Cheers,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> > > > (of course, if we do, then that might be one more
> > > > argument for moving Veltag into the tools project).
> > > +1
> > -0.1 and the only reason i'm not -1 on this is that i do see
> > an arguable connection, where velocity web/servlet stuff (particularly,
> > replacing JSP) is a core competency of veltools.
>
> Lol... Nathan, I thought you were originally saying that you -wanted- to
> move Veltag into VelocityTools, so I thought I was agreeing with you. Ha.
nope, i'm wavering but still leaning slightly against it. :)
...
> I'm talking about how the Velocity website ... Tools already
> lumps a bunch of stuff under a "Tools" menu umbrella
> (http://jakarta.apache.org/velocity/).
ah. the website. yeah, i thought you were just talking about the actual
projects/distros. (as you do below...)
> That doesn't make it obvious why Anakia/Texen are in velocity.jar, but DVSL
> and Veltag are not, and "Velocity Tools" is a sub-project of Tools that has
> "tools" in it. Boggles the mind and I've been using this stuff for ages. ;-)
now you're mixing up website and distro stuff. VelocityTools may be under a
"Tools" heading on the website, but it's not a subproject of anything but core
Velocity. i agree that Anakia/Texen probably ought to be moved out of the
core, but i just don't want them in VelocityTools. :)
...
> Ex. Nathan wants latest news at the top, because he already knows what
> Velocity and VelocityTools is all about and never reads the "What is topic."
> But a new user won't find the description because it is buried. In fact, the
> "Overview" link does not give an overview... it gives seemingly random info
> "Velocity v 1.4. Released", "Notice: JDOM API Change" and
> "Velocity News" are all that fit on my screen. Where in there is the
> "Overview?"
>
> Another potentially logical place to find "What is this thing" is the
> "Getting started" link -- which says, "go read the Users/Developers
> Guide"... but at this point, the user still might not even understand what
> the heck Velocity does, so it is unlikely they will invest time reading a
> manual to find out.
yeah, the main website could use some work. no arguement there. but i also
don't have time to provide patches. :(
...
> On the topic of separate projects:
> > keep separate things in separate projects.
> Funny thing is that I agree, that is my intention -- i.e. move non-core
> stuff out of Velocity and into a separate project.
> (But here is the problem, if Anakia is not a Velocity "tool" -- as it has
> been listed in the menu for years, then I really don't know where to put
> it.)
c'mon. i'm not saying it's not a tool in the general sense of the term. if
you can explain to me how Anakia is similar in function/use/purpose to the
contents of the VelocityTools project, i'll listen. but please don't appeal
to the dictionary or main website as arguments for its inclusion therein. if
anything, Anakia would fit better with dvsl, as they are both xml
transformation tools.
> I certainly do not want separate tiny sub-projects for every 6 classe that
> make up a 'tool'. That'd be a pain.
says you. the following suggestion sounds more painful to me.
> The way VelocityTools contains
> generic/struts/view tools and creates multiple jars seems like a Good Thing
> that could be replicated for org.apache.velocity.tools.anakia.* and
> org.apache.velocity.tools.texen.* and produce separate jars for those
> tools.... and veltag... and DVSL...and whatever else.
>
> Regarding tying "VelocityTools" releases to Anakia... uh, right now if
> Anakia breaks (cough cough... JDOM error), that would tie up Velocity core
> Releases...which seems more important to me.
yeah, but if Anakia/Texen were separate, then problems with them wouldn't hold
up releases of either the core or veltools. :) just because veltools is less
important than the core is no reason to saddle the project with things it's
developers don't want.
> So no, I wouldn't mind seeing the 9 anakia.* classes and 6 texen.* moved
> into tools.* under VelocityTools.
>
> In fact, I'll put my money where my mouth is.... <grin>
> Even though I don't use Anakia or Texen, and rarely use Veltag and DVSL -->
> I'll volunteer to move them.
moving them is nothing. maintaining them and their docs is another. oh, and
i still haven't heard you justify their inclusion with something better than
the vague semantics of the word "tool." i can't help but wonder if we'd even
be having this discussion if VelocityTools had a more creative and/or specific
name. but alas, the name predates my involvement. :(
> So Nathan, if you still don't want them in there, that's cool... stubborn
> beyond my belief <grin>, but I'll drop the thread. :-P
i've never been accused of being a pushover. :) you're welcome to keep the
thread going though. if you can sway all the core developers and the other
veltools committers to be +1 on this idea, then i might be willing to vote -0
on the idea. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Velocity Core and Tools separation
Posted by Tim Colson <tc...@cisco.com>.
> > > (of course, if we do, then that might be one more
> > > argument for moving Veltag into the tools project).
> > +1
> -0.1 and the only reason i'm not -1 on this is that i do see
> an arguable connection, where velocity web/servlet stuff (particularly,
> replacing JSP) is a core competency of veltools.
Lol... Nathan, I thought you were originally saying that you -wanted- to
move Veltag into VelocityTools, so I thought I was agreeing with you. Ha.
> i promise to veto this. :) Tools is not an umbrella, nor
Heh heh... I'm talking about how the Velocity website ... Tools already
lumps a bunch of stuff under a "Tools" menu umbrella
(http://jakarta.apache.org/velocity/). Veto that. <grin>
That doesn't make it obvious why Anakia/Texen are in velocity.jar, but DVSL
and Veltag are not, and "Velocity Tools" is a sub-project of Tools that has
"tools" in it. Boggles the mind and I've been using this stuff for ages. ;-)
Remember folks -- this weird structure kind of makes sense because we have
been living and breathing it for years... but that doesn't mean it makes any
sense, especially to new folks.
What's worse -- we're all tainted. Usability testing cannot be done by those
who built the system. They know 'too much'.
Ex. Nathan wants latest news at the top, because he already knows what
Velocity and VelocityTools is all about and never reads the "What is topic."
But a new user won't find the description because it is buried. In fact, the
"Overview" link does not give an overview... it gives seemingly random info
"Velocity v 1.4. Released", "Notice: JDOM API Change" and "Velocity News"
are all that fit on my screen. Where in there is the "Overview?"
Another potentially logical place to find "What is this thing" is the
"Getting started" link -- which says, "go read the Users/Developers
Guide"... but at this point, the user still might not even understand what
the heck Velocity does, so it is unlikely they will invest time reading a
manual to find out.
I ask other developers/vendors about Velocity support all the time... and
many come back with, "Yeah... I've kinda looked at it... not sure what
Velocity does."
Meanwhile, everybody seems to grok [the eevil that is] JSP. ;-)
Obviously that is due to more than just the website, but regardless, a thing
or two could be learned from: http://java.sun.com/products/jsp/
On the topic of separate projects:
> keep separate things in separate projects.
Funny thing is that I agree, that is my intention -- i.e. move non-core
stuff out of Velocity and into a separate project.
(But here is the problem, if Anakia is not a Velocity "tool" -- as it has
been listed in the menu for years, then I really don't know where to put
it.)
I certainly do not want separate tiny sub-projects for every 6 classe that
make up a 'tool'. That'd be a pain. The way VelocityTools contains
generic/struts/view tools and creates multiple jars seems like a Good Thing
that could be replicated for org.apache.velocity.tools.anakia.* and
org.apache.velocity.tools.texen.* and produce separate jars for those
tools.... and veltag... and DVSL...and whatever else.
Regarding tying "VelocityTools" releases to Anakia... uh, right now if
Anakia breaks (cough cough... JDOM error), that would tie up Velocity core
Releases...which seems more important to me.
So no, I wouldn't mind seeing the 9 anakia.* classes and 6 texen.* moved
into tools.* under VelocityTools.
In fact, I'll put my money where my mouth is.... <grin>
Even though I don't use Anakia or Texen, and rarely use Veltag and DVSL -->
I'll volunteer to move them.
So Nathan, if you still don't want them in there, that's cool... stubborn
beyond my belief <grin>, but I'll drop the thread. :-P
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Nathan wrote:
> > (of course, if we do, then that might be one more
> > argument for moving Veltag into the tools project).
> +1
-0.1 and the only reason i'm not -1 on this is that i do see an arguable
connection, where velocity web/servlet stuff (particularly, replacing JSP) is
a core competency of veltools.
> My 1.5 cents -- moving non-core stuff into Veltools would help reduce
> confusion for new users (and existing dumb users like me <grin>).
-1 for the reasons well-explained by Mike K.
> Maybe for 1.5 the VelocityServlet could be deprecated and/or removed?
it is already deprecated in 1.5.
> And personally -- I'd pull Anakia out of core and into tools too.
> Basically anything on the Velocity Homepage listed under "Tools" could move
> into the Velocity Tools Big Umbrella.
i promise to veto this. :) Tools is not an umbrella, nor will it be if i have
anything to say about it. in fact, i don't think umbrella projects are a good
idea. keep separate things in separate projects.
> I'd bet Nathan doesn't want Anakia/DVSL/Texen/Foo in Tools because he
> doesn't want to support them,
yep. and i'd say that's a darn good reason not to do it. seriously, do you
really want VelocityTools releases to be held up because there's some issue
with Anakia or DVSL (which i don't know or use) that the primary VelocityTools
developers don't know to deal with or care to dig into because they're totally
separate products that they don't know or use? i don't think you'd like this
in the long run.
> but I see moving them as just a logical thing...
it's not when it comes time to release things.
> support would be from whoever cares to support them. I mean, it's
> not like Velocity and VelocityTools have separate mailing lists. ;-)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Core and Tools separation
Posted by Mike Kienenberger <mk...@alaska.net>.
Tim Colson <tc...@cisco.com> wrote:
> Nathan wrote:
> > (of course, if we do, then that might be one more
> > argument for moving Veltag into the tools project).
> +1
>
> My 1.5 cents -- moving non-core stuff into Veltools would help reduce
> confusion for new users (and existing dumb users like me <grin>).
>
> Maybe for 1.5 the VelocityServlet could be deprecated and/or removed?
> And personally -- I'd pull Anakia out of core and into tools too.
> Basically anything on the Velocity Homepage listed under "Tools" could
move
> into the Velocity Tools Big Umbrella.
>
> I'd bet Nathan doesn't want Anakia/DVSL/Texen/Foo in Tools because he
> doesn't want to support them, but I see moving them as just a logical
> thing... support would be from whoever cares to support them. I mean, it's
> not like Velocity and VelocityTools have separate mailing lists. ;-)
-1
Start another subproject if it's not really part of the "Velocity Tools"
project.
Just because it's named "Velocity Tools" doesn't mean that anything that
meets the generic definition of tool should be there.
The tools we're talking about are those listed in the toolbox.xml file, not
hammers or struts or veloedit or whatever, all of which are tools in the
generic sense.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Velocity Core and Tools separation
Posted by Tim Colson <tc...@cisco.com>.
Nathan wrote:
> (of course, if we do, then that might be one more
> argument for moving Veltag into the tools project).
+1
My 1.5 cents -- moving non-core stuff into Veltools would help reduce
confusion for new users (and existing dumb users like me <grin>).
Maybe for 1.5 the VelocityServlet could be deprecated and/or removed?
And personally -- I'd pull Anakia out of core and into tools too.
Basically anything on the Velocity Homepage listed under "Tools" could move
into the Velocity Tools Big Umbrella.
I'd bet Nathan doesn't want Anakia/DVSL/Texen/Foo in Tools because he
doesn't want to support them, but I see moving them as just a logical
thing... support would be from whoever cares to support them. I mean, it's
not like Velocity and VelocityTools have separate mailing lists. ;-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: More Veltag questions...
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> Could we get this as a patch to what's in CVS ? :)
heh. i didn't really think you'd want to make VelocityTools a dependency of
Veltag. (of course, if we do, then that might be one more argument for moving
Veltag into the tools project). anyway, if Arindam doesn't beat me to it,
i'll see if i can whip up a patch for you today or this weekend. :)
> On Apr 16, 2004, at 3:05 PM, Nathan Bubna wrote:
>
> > Gupta, Arindam said:
> >> Received the following errors while compiling:
> > ...
> >> D:\VelocitySource\jakarta-
> >> velocity\contrib\temporary\veltag\src\java\org
> >> \apache\taglibs\velocity\JSPContext.java:41: cannot resolve symbol
> >> [javac] symbol : constructor ChainedContext
> >> (<nulltype>,javax.servlet.ServletRequest,javax.servlet.ServletResponse
> >> ,j
> >> avax.servlet.ServletContext)
> >> [javac] location: class
> >> org.apache.velocity.tools.view.context.ChainedContext
> >> [javac] super(null,
> >> [javac] ^
> >
> > oh, yeah. you'll have to cast the ServletRequest and ServletResponse
> > to
> > HttpServletRequest and HttpServletResponse.
> >
> >> D:\VelocitySource\jakarta-
> >> velocity\contrib\temporary\veltag\src\java\org
> >> \apache\taglibs\velocity\VelocityTag.java:185: cannot resolve symbol
> >> [javac] symbol : variable TOOLBOX_KEY
> > ...
> >
> > add this to VelocityTag:
> >
> > /**
> > * Key used to access the toolbox configuration file path from the
> > * Servlet or webapp init parameters
> > ("org.apache.velocity.toolbox").
> > */
> > protected static final String TOOLBOX_KEY =
> > "org.apache.velocity.toolbox";
> >
> >
> >> I had to add a couple of import statements in the VelocityTag.java and
> >> fix a semi-colon.
> >
> > yeah, like i said, i threw it together "hastily" (i.e. in about 10
> > minutes)
> > and hadn't even tried compiling yet. sorry. :-/
> >
> >> I will send out the final code once I have tested it.
> > ...
> >
> > that'd be great. thanks!
...
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org