You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Matt Benson <gu...@yahoo.com> on 2007/06/01 23:47:24 UTC
[anakia] discussion of recent refactoring
Hi--you will find me to be a complete novice to
Velocity and Anakia; nevertheless I have come to spoil
the fun. ;) Actually I feel like my timing is pretty
good as I have come to talk about further changes to
the recent Anakia refactorings: I say my timing is
good because it appears the changes to which I refer
were made post-1.0 and therefore further refactoring
will not result in backward compatibility issues
(please advise if I am mistaken about this).
I'll take this brief moment to--possibly
unnecessarily--introduce myself (I think several of
the key Velocity players are familiar to me from the
jakarta and commons dev lists). I am a Jakarta
(commons) committer as well as a member of the Ant
PMC. I have begun looking into Anakia recently and
with my Ant hat on I'd like to make some suggestions.
I would provide my suggestions in the form of patches
but I'm unfortunately not yet clueful enough wrt to
Anakia/Velocity codebases.
With all that out of the way, to the one or two or you
who may still be paying attention: I'm sure it should
surprise no one for me to accuse the AnakiaTask of
being very old-school Ant; it predates my use of Ant
(let alone my actual involvement). For BC reasons, at
least for now, that's fine; however, with the Anakia
class having been recently extracted from the
AnakiaTask, I see no reason whatsoever that the Anakia
processor itself cannot be written in a more abstract
way. In particular I'd like to discuss the idea of
reusing Velocity's Resource (and related) concept(s)
here, giving the Ant task more responsibilty with
regard to providing Ant (small 'r') resources in terms
of Velocity Resources. This would allow the
AnakiaTask v1.x to remain compatible with Ant 1.6
(possibly/probably earlier versions but that's the
version in the POM), while allowing other clients of
the Anakia processor to be more agile, particularly by
permitting the use of non-file resources.
A directly related issue is that Ant 1.7.0 and beyond
greatly extend Ant's own Resource concept such that
adapters from Ant Resources to Velocity Resources, and
related other adapters, should be fairly trivial to
write: a 1.7-specific AnakiaTask could be quite an
advance over the current implementation in terms of
capability.
My initial investigation into the Anakia/Velocity code
indicates that there may be some Velocity-specific
idiosyncrasies with regard to ResourceLoader
configuration, etc., so I have as yet been unable to
determine the correct steps to take in modifying the
Anakia processor class to use Resources. I present my
case here hoping for some direction from experienced
Velocity developers.
Regards,
Matt
____________________________________________________________________________________
Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [anakia] discussion of recent refactoring
Posted by Will Glass-Husain <wg...@gmail.com>.
Hi,
Matt-- thanks for being interested in further development of Anakia. If
there's ant 1.7-specific things you want to do - go for it. I've no problem
with jumping from Anakia 1.0 to Anakia 2.0 as a signal of backwards
incompatility.
Developing a custom resource loader is pretty straight forward. You might
look at my slides "Hacking Velocity" from ApacheCon 2004.
http://wiki.apache.org/velocity/HackingVelocity
All you need to do is implement the ResourceLoader interface. Look at the
source code for FileResourceLoader or the simple ClasspathResourceLoader.
Or is your question how to use a ResourceLoader to retrieve a template?
You're wrong by the way that only one type can be used -- you can configure
Velocity to use multiple resource loaders and search them in order.
WILL
On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
>
>
> --- Nathan Bubna <nb...@gmail.com> wrote:
>
> > On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
> > > Hi--you will find me to be a complete novice to
> > > Velocity and Anakia; nevertheless I have come to
> > spoil
> > > the fun. ;) Actually I feel like my timing is
> > pretty
> > > good as I have come to talk about further changes
> > to
> > > the recent Anakia refactorings: I say my timing
> > is
> > > good because it appears the changes to which I
> > refer
> > > were made post-1.0 and therefore further
> > refactoring
> > > will not result in backward compatibility issues
> > > (please advise if I am mistaken about this).
> >
> > not quite sure what you mean. it's hard to tell if
> > further
> > refactoring will cause BC issues without know what
> > the refactoring
> > involves. in any case, we could always do an Anakia
> > 2.0, if the
> > further refactoring was sufficient to warrant it.
>
> My thought process was that Anakia as a standalone
> class has not yet been released into the wild, so no
> matter what is done to it there are no BC issues. An
> Ant 1.7-compatible Anakia task would probably indicate
> Anakia v2.0.
>
> >
> > > I'll take this brief moment to--possibly
> > > unnecessarily--introduce myself (I think several
> > of
> > > the key Velocity players are familiar to me from
> > the
> > > jakarta and commons dev lists). I am a Jakarta
> > > (commons) committer as well as a member of the Ant
> > > PMC. I have begun looking into Anakia recently
> > and
> > > with my Ant hat on I'd like to make some
> > suggestions.
> > > I would provide my suggestions in the form of
> > patches
> > > but I'm unfortunately not yet clueful enough wrt
> > to
> > > Anakia/Velocity codebases.
> >
> > we can help there. anything in particular you'd
> > like to know?
>
> I see. You're gonna go "smart questions" on me. ;)
>
> >
> > > With all that out of the way, to the one or two or
> > you
> > > who may still be paying attention: I'm sure it
> > should
> > > surprise no one for me to accuse the AnakiaTask of
> > > being very old-school Ant; it predates my use of
> > Ant
> > > (let alone my actual involvement). For BC
> > reasons, at
> > > least for now, that's fine; however, with the
> > Anakia
> > > class having been recently extracted from the
> > > AnakiaTask, I see no reason whatsoever that the
> > Anakia
> > > processor itself cannot be written in a more
> > abstract
> > > way. In particular I'd like to discuss the idea
> > of
> > > reusing Velocity's Resource (and related)
> > concept(s)
> > > here, giving the Ant task more responsibilty with
> > > regard to providing Ant (small 'r') resources in
> > terms
> > > of Velocity Resources. This would allow the
> > > AnakiaTask v1.x to remain compatible with Ant 1.6
> > > (possibly/probably earlier versions but that's the
> > > version in the POM), while allowing other clients
> > of
> > > the Anakia processor to be more agile,
> > particularly by
> > > permitting the use of non-file resources.
> > >
> > > A directly related issue is that Ant 1.7.0 and
> > beyond
> > > greatly extend Ant's own Resource concept such
> > that
> > > adapters from Ant Resources to Velocity Resources,
> > and
> > > related other adapters, should be fairly trivial
> > to
> > > write: a 1.7-specific AnakiaTask could be quite
> > an
> > > advance over the current implementation in terms
> > of
> > > capability.
> >
> > not that Anakia or Ant are my fortes, but this
> > sounds like a good way to go.
>
> Glad to hear it.
>
> >
> > > My initial investigation into the Anakia/Velocity
> > code
> > > indicates that there may be some Velocity-specific
> > > idiosyncrasies with regard to ResourceLoader
> > > configuration, etc., so I have as yet been unable
> > to
> > > determine the correct steps to take in modifying
> > the
> > > Anakia processor class to use Resources. I
> > present my
> > > case here hoping for some direction from
> > experienced
> > > Velocity developers.
> >
> > sure. got any specific questions here? or are you
> > looking for a
> > general primer on Velocity ResourceLoaders?
>
> Sort of the latter, yes. There simply seems to be a
> lot of magic involved; I've seen implications that
> only one e.g. "file" ResourceLoader can be active for
> a VelocityEngine, and similar things that strike me
> funny. If there is a current "Resource guru" in
> Velocity-land who could provide an overview, that
> would certainly be welcome. Quick looks at the
> ResourceManagerImpl didn't leave me with a strong
> impression of what level of customization is intended
> to be supported.
>
> -Matt
>
> >
> > > Regards,
> > > Matt
> > >
> > >
> > >
> > >
> > >
> >
>
> ____________________________________________________________________________________
> > > Choose the right car based on your needs. Check
> > out Yahoo! Autos new Car Finder tool.
> > > http://autos.yahoo.com/carfinder/
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > dev-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail:
> > dev-help@velocity.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail:
> > dev-help@velocity.apache.org
> >
> >
>
>
>
>
>
> ____________________________________________________________________________________
> Be a better Globetrotter. Get better travel answers from someone who
> knows. Yahoo! Answers - Check it out.
> http://answers.yahoo.com/dir/?link=list&sid=396545469
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: [anakia] discussion of recent refactoring
Posted by Nathan Bubna <nb...@gmail.com>.
On 6/3/07, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Nathan Bubna <nb...@gmail.com> wrote:
<snip/>
> > The last thing that might be handy to know is that
> > you can also feed
> > an already instantiated ResourceLoader into the
> > system (rather than
> > have it be loaded and instantiated by class name).
> > If you want more
> > details on that, ask away. :)
> >
>
> This is the most interesting thing to me--it seems
> like a reasonable assertion to say that other APIs
> intending to use Velocity under the covers would be
> justified in doing things in as much a Java-centric,
> and consequently as little a Velocity-centric way, and
> being able to easily set up the ResourceLoader without
> having to rely too much on Velocity's internal
> machinery would seem to significantly decrease the
> ramp-up time to productivity. IOW, I would definitely
> like to know more about this subject. :)
ok, i haven't used this myself; i've only noticed it in the code. so,
this may be trickier than it seems. but here's what i see...
create or instantiate your ResourceLoader subclass...
ResourceLoader fooLoader = new FooResourceLoader();
get a handle for the Properties file you'll be using to call
velocityEngine.init(properties) with.
then, *before* you call velocityEngine.init(properties) do:
properties.setProperty("resource.loader", "foo");
properties.put("foo.resource.loader.instance", fooLoader);
then you can call velocityEngine.init(properties);
the ResourceManagerImpl should then find your ready-to-go resource
loader instance and use that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [anakia] discussion of recent refactoring
Posted by Matt Benson <gu...@yahoo.com>.
--- Nathan Bubna <nb...@gmail.com> wrote:
> On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
[SNIP]
> > lot of magic involved; I've seen implications that
> > only one e.g. "file" ResourceLoader can be active
> for
> > a VelocityEngine, and similar things that strike
> me
> > funny.
>
> You can definitely have as many FileResourceLoaders
> as you want,
> either per engine or per app, you just can't name
> them all "file".
> Try "file2" or "otherfile" for latter ones. :)
> However, i don't know
> of many usecases for having multiple
> FileResourceLoaders. Most often
> you find people mixing different resource loader
> impls. Such as a
> FileResourceLoader and a ClasspathResourceLoader.
> or a WebappLoader
> (from VelocityTools) and a DataSourceResourceLoader.
>
My superficial understanding of anakia is that it
configures a VelocityEngine to use the "file" resource
loader, then uses a basedir and file paths to locate
xml files from which it creates DOMs to shove into the
velocity context. It seems to me more natural to use
another file-based ResourceLoader to locate the XML
files, you see?
> The StringResourceLoader has some pretty serious
> flaws in Velocity
> 1.5, so you can currently only use one per JVM.
> This has been fixed
> for Velocity 1.6, though.
Probably immaterial here. :)
>
> > If there is a current "Resource guru" in
> > Velocity-land who could provide an overview, that
> > would certainly be welcome. Quick looks at the
> > ResourceManagerImpl didn't leave me with a strong
> > impression of what level of customization is
> intended
> > to be supported.
>
> I dunno if there's a "resource guru", but you'd find
> me pretty hard to
> stump when it comes to Velocity resource loading. :)
>
> Typically, most apps using Velocity need little more
> than customizing
> resource loader settings in their
> velocity.properties. We provide
> ResourceLoader impls for loading from the file
> system, servlet
> context, databases, classpaths, and
> java.lang.Strings. Most users
> just need to configure those a little or a lot.
>
> The next level is implementing your own
> ResourceLoader subclass. I
> don't think this happens much outside of frameworks
> who are
> integrating Velocity into their framework. So far
> it sounds like this
> is what you'll need to do.
For the Ant 1.7-compatible Anakia 2.0 branch, yes.
>
> The ResourceManagerImpl manages the ResourceLoaders
> and the
> ResourceCache. Since you can plug in your own
> loaders and cache,
> implementing your own ResourceManager is something
> i've never seen
> cause for. I don't recall anyone ever asking about
> it either. I
> doubt you'd need or want to do this, but who knows?
> There's a first
> time for everything.
I agree, it doesn't look like I'd need this.
>
> Plugging in your own ResourceCache also seems
> somewhat unlikely to be
> necessary, but this can be done if you're not happy
> merely configuring
> the size of the LRU cache used in the default impl.
>
> The last thing that might be handy to know is that
> you can also feed
> an already instantiated ResourceLoader into the
> system (rather than
> have it be loaded and instantiated by class name).
> If you want more
> details on that, ask away. :)
>
This is the most interesting thing to me--it seems
like a reasonable assertion to say that other APIs
intending to use Velocity under the covers would be
justified in doing things in as much a Java-centric,
and consequently as little a Velocity-centric way, and
being able to easily set up the ResourceLoader without
having to rely too much on Velocity's internal
machinery would seem to significantly decrease the
ramp-up time to productivity. IOW, I would definitely
like to know more about this subject. :)
-Matt
> > -Matt
> >
> > >
> > > > Regards,
> > > > Matt
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
____________________________________________________________________________________
> > > > Choose the right car based on your needs.
> Check
> > > out Yahoo! Autos new Car Finder tool.
> > > > http://autos.yahoo.com/carfinder/
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@velocity.apache.org
> > > > For additional commands, e-mail:
> > > dev-help@velocity.apache.org
> > > >
> > > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > dev-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail:
> > > dev-help@velocity.apache.org
> > >
> > >
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Be a better Globetrotter. Get better travel
> answers from someone who knows. Yahoo! Answers -
> Check it out.
> >
>
http://answers.yahoo.com/dir/?link=list&sid=396545469
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail:
> dev-help@velocity.apache.org
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail:
> dev-help@velocity.apache.org
>
>
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [anakia] discussion of recent refactoring
Posted by Nathan Bubna <nb...@gmail.com>.
On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Nathan Bubna <nb...@gmail.com> wrote:
>
> > On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
> > > Hi--you will find me to be a complete novice to
> > > Velocity and Anakia; nevertheless I have come to
> > spoil
> > > the fun. ;) Actually I feel like my timing is
> > pretty
> > > good as I have come to talk about further changes
> > to
> > > the recent Anakia refactorings: I say my timing
> > is
> > > good because it appears the changes to which I
> > refer
> > > were made post-1.0 and therefore further
> > refactoring
> > > will not result in backward compatibility issues
> > > (please advise if I am mistaken about this).
> >
> > not quite sure what you mean. it's hard to tell if
> > further
> > refactoring will cause BC issues without know what
> > the refactoring
> > involves. in any case, we could always do an Anakia
> > 2.0, if the
> > further refactoring was sufficient to warrant it.
>
> My thought process was that Anakia as a standalone
> class has not yet been released into the wild, so no
> matter what is done to it there are no BC issues. An
> Ant 1.7-compatible Anakia task would probably indicate
> Anakia v2.0.
Gotcha. Yes, Anakia as a standalone class is unreleased and thus very
open to change.
> >
> > > I'll take this brief moment to--possibly
> > > unnecessarily--introduce myself (I think several
> > of
> > > the key Velocity players are familiar to me from
> > the
> > > jakarta and commons dev lists). I am a Jakarta
> > > (commons) committer as well as a member of the Ant
> > > PMC. I have begun looking into Anakia recently
> > and
> > > with my Ant hat on I'd like to make some
> > suggestions.
> > > I would provide my suggestions in the form of
> > patches
> > > but I'm unfortunately not yet clueful enough wrt
> > to
> > > Anakia/Velocity codebases.
> >
> > we can help there. anything in particular you'd
> > like to know?
>
> I see. You're gonna go "smart questions" on me. ;)
i've been known to do such things.. ;)
> >
> > > With all that out of the way, to the one or two or
> > you
> > > who may still be paying attention: I'm sure it
> > should
> > > surprise no one for me to accuse the AnakiaTask of
> > > being very old-school Ant; it predates my use of
> > Ant
> > > (let alone my actual involvement). For BC
> > reasons, at
> > > least for now, that's fine; however, with the
> > Anakia
> > > class having been recently extracted from the
> > > AnakiaTask, I see no reason whatsoever that the
> > Anakia
> > > processor itself cannot be written in a more
> > abstract
> > > way. In particular I'd like to discuss the idea
> > of
> > > reusing Velocity's Resource (and related)
> > concept(s)
> > > here, giving the Ant task more responsibilty with
> > > regard to providing Ant (small 'r') resources in
> > terms
> > > of Velocity Resources. This would allow the
> > > AnakiaTask v1.x to remain compatible with Ant 1.6
> > > (possibly/probably earlier versions but that's the
> > > version in the POM), while allowing other clients
> > of
> > > the Anakia processor to be more agile,
> > particularly by
> > > permitting the use of non-file resources.
> > >
> > > A directly related issue is that Ant 1.7.0 and
> > beyond
> > > greatly extend Ant's own Resource concept such
> > that
> > > adapters from Ant Resources to Velocity Resources,
> > and
> > > related other adapters, should be fairly trivial
> > to
> > > write: a 1.7-specific AnakiaTask could be quite
> > an
> > > advance over the current implementation in terms
> > of
> > > capability.
> >
> > not that Anakia or Ant are my fortes, but this
> > sounds like a good way to go.
>
> Glad to hear it.
>
> >
> > > My initial investigation into the Anakia/Velocity
> > code
> > > indicates that there may be some Velocity-specific
> > > idiosyncrasies with regard to ResourceLoader
> > > configuration, etc., so I have as yet been unable
> > to
> > > determine the correct steps to take in modifying
> > the
> > > Anakia processor class to use Resources. I
> > present my
> > > case here hoping for some direction from
> > experienced
> > > Velocity developers.
> >
> > sure. got any specific questions here? or are you
> > looking for a
> > general primer on Velocity ResourceLoaders?
>
> Sort of the latter, yes. There simply seems to be a
> lot of magic involved; I've seen implications that
> only one e.g. "file" ResourceLoader can be active for
> a VelocityEngine, and similar things that strike me
> funny.
You can definitely have as many FileResourceLoaders as you want,
either per engine or per app, you just can't name them all "file".
Try "file2" or "otherfile" for latter ones. :) However, i don't know
of many usecases for having multiple FileResourceLoaders. Most often
you find people mixing different resource loader impls. Such as a
FileResourceLoader and a ClasspathResourceLoader. or a WebappLoader
(from VelocityTools) and a DataSourceResourceLoader.
The StringResourceLoader has some pretty serious flaws in Velocity
1.5, so you can currently only use one per JVM. This has been fixed
for Velocity 1.6, though.
> If there is a current "Resource guru" in
> Velocity-land who could provide an overview, that
> would certainly be welcome. Quick looks at the
> ResourceManagerImpl didn't leave me with a strong
> impression of what level of customization is intended
> to be supported.
I dunno if there's a "resource guru", but you'd find me pretty hard to
stump when it comes to Velocity resource loading. :)
Typically, most apps using Velocity need little more than customizing
resource loader settings in their velocity.properties. We provide
ResourceLoader impls for loading from the file system, servlet
context, databases, classpaths, and java.lang.Strings. Most users
just need to configure those a little or a lot.
The next level is implementing your own ResourceLoader subclass. I
don't think this happens much outside of frameworks who are
integrating Velocity into their framework. So far it sounds like this
is what you'll need to do.
The ResourceManagerImpl manages the ResourceLoaders and the
ResourceCache. Since you can plug in your own loaders and cache,
implementing your own ResourceManager is something i've never seen
cause for. I don't recall anyone ever asking about it either. I
doubt you'd need or want to do this, but who knows? There's a first
time for everything.
Plugging in your own ResourceCache also seems somewhat unlikely to be
necessary, but this can be done if you're not happy merely configuring
the size of the LRU cache used in the default impl.
The last thing that might be handy to know is that you can also feed
an already instantiated ResourceLoader into the system (rather than
have it be loaded and instantiated by class name). If you want more
details on that, ask away. :)
> -Matt
>
> >
> > > Regards,
> > > Matt
> > >
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________________________________
> > > Choose the right car based on your needs. Check
> > out Yahoo! Autos new Car Finder tool.
> > > http://autos.yahoo.com/carfinder/
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > dev-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail:
> > dev-help@velocity.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail:
> > dev-help@velocity.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
> http://answers.yahoo.com/dir/?link=list&sid=396545469
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [anakia] discussion of recent refactoring
Posted by Matt Benson <gu...@yahoo.com>.
--- Nathan Bubna <nb...@gmail.com> wrote:
> On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
> > Hi--you will find me to be a complete novice to
> > Velocity and Anakia; nevertheless I have come to
> spoil
> > the fun. ;) Actually I feel like my timing is
> pretty
> > good as I have come to talk about further changes
> to
> > the recent Anakia refactorings: I say my timing
> is
> > good because it appears the changes to which I
> refer
> > were made post-1.0 and therefore further
> refactoring
> > will not result in backward compatibility issues
> > (please advise if I am mistaken about this).
>
> not quite sure what you mean. it's hard to tell if
> further
> refactoring will cause BC issues without know what
> the refactoring
> involves. in any case, we could always do an Anakia
> 2.0, if the
> further refactoring was sufficient to warrant it.
My thought process was that Anakia as a standalone
class has not yet been released into the wild, so no
matter what is done to it there are no BC issues. An
Ant 1.7-compatible Anakia task would probably indicate
Anakia v2.0.
>
> > I'll take this brief moment to--possibly
> > unnecessarily--introduce myself (I think several
> of
> > the key Velocity players are familiar to me from
> the
> > jakarta and commons dev lists). I am a Jakarta
> > (commons) committer as well as a member of the Ant
> > PMC. I have begun looking into Anakia recently
> and
> > with my Ant hat on I'd like to make some
> suggestions.
> > I would provide my suggestions in the form of
> patches
> > but I'm unfortunately not yet clueful enough wrt
> to
> > Anakia/Velocity codebases.
>
> we can help there. anything in particular you'd
> like to know?
I see. You're gonna go "smart questions" on me. ;)
>
> > With all that out of the way, to the one or two or
> you
> > who may still be paying attention: I'm sure it
> should
> > surprise no one for me to accuse the AnakiaTask of
> > being very old-school Ant; it predates my use of
> Ant
> > (let alone my actual involvement). For BC
> reasons, at
> > least for now, that's fine; however, with the
> Anakia
> > class having been recently extracted from the
> > AnakiaTask, I see no reason whatsoever that the
> Anakia
> > processor itself cannot be written in a more
> abstract
> > way. In particular I'd like to discuss the idea
> of
> > reusing Velocity's Resource (and related)
> concept(s)
> > here, giving the Ant task more responsibilty with
> > regard to providing Ant (small 'r') resources in
> terms
> > of Velocity Resources. This would allow the
> > AnakiaTask v1.x to remain compatible with Ant 1.6
> > (possibly/probably earlier versions but that's the
> > version in the POM), while allowing other clients
> of
> > the Anakia processor to be more agile,
> particularly by
> > permitting the use of non-file resources.
> >
> > A directly related issue is that Ant 1.7.0 and
> beyond
> > greatly extend Ant's own Resource concept such
> that
> > adapters from Ant Resources to Velocity Resources,
> and
> > related other adapters, should be fairly trivial
> to
> > write: a 1.7-specific AnakiaTask could be quite
> an
> > advance over the current implementation in terms
> of
> > capability.
>
> not that Anakia or Ant are my fortes, but this
> sounds like a good way to go.
Glad to hear it.
>
> > My initial investigation into the Anakia/Velocity
> code
> > indicates that there may be some Velocity-specific
> > idiosyncrasies with regard to ResourceLoader
> > configuration, etc., so I have as yet been unable
> to
> > determine the correct steps to take in modifying
> the
> > Anakia processor class to use Resources. I
> present my
> > case here hoping for some direction from
> experienced
> > Velocity developers.
>
> sure. got any specific questions here? or are you
> looking for a
> general primer on Velocity ResourceLoaders?
Sort of the latter, yes. There simply seems to be a
lot of magic involved; I've seen implications that
only one e.g. "file" ResourceLoader can be active for
a VelocityEngine, and similar things that strike me
funny. If there is a current "Resource guru" in
Velocity-land who could provide an overview, that
would certainly be welcome. Quick looks at the
ResourceManagerImpl didn't leave me with a strong
impression of what level of customization is intended
to be supported.
-Matt
>
> > Regards,
> > Matt
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Choose the right car based on your needs. Check
> out Yahoo! Autos new Car Finder tool.
> > http://autos.yahoo.com/carfinder/
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail:
> dev-help@velocity.apache.org
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail:
> dev-help@velocity.apache.org
>
>
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [anakia] discussion of recent refactoring
Posted by Nathan Bubna <nb...@gmail.com>.
On 6/1/07, Matt Benson <gu...@yahoo.com> wrote:
> Hi--you will find me to be a complete novice to
> Velocity and Anakia; nevertheless I have come to spoil
> the fun. ;) Actually I feel like my timing is pretty
> good as I have come to talk about further changes to
> the recent Anakia refactorings: I say my timing is
> good because it appears the changes to which I refer
> were made post-1.0 and therefore further refactoring
> will not result in backward compatibility issues
> (please advise if I am mistaken about this).
not quite sure what you mean. it's hard to tell if further
refactoring will cause BC issues without know what the refactoring
involves. in any case, we could always do an Anakia 2.0, if the
further refactoring was sufficient to warrant it.
> I'll take this brief moment to--possibly
> unnecessarily--introduce myself (I think several of
> the key Velocity players are familiar to me from the
> jakarta and commons dev lists). I am a Jakarta
> (commons) committer as well as a member of the Ant
> PMC. I have begun looking into Anakia recently and
> with my Ant hat on I'd like to make some suggestions.
> I would provide my suggestions in the form of patches
> but I'm unfortunately not yet clueful enough wrt to
> Anakia/Velocity codebases.
we can help there. anything in particular you'd like to know?
> With all that out of the way, to the one or two or you
> who may still be paying attention: I'm sure it should
> surprise no one for me to accuse the AnakiaTask of
> being very old-school Ant; it predates my use of Ant
> (let alone my actual involvement). For BC reasons, at
> least for now, that's fine; however, with the Anakia
> class having been recently extracted from the
> AnakiaTask, I see no reason whatsoever that the Anakia
> processor itself cannot be written in a more abstract
> way. In particular I'd like to discuss the idea of
> reusing Velocity's Resource (and related) concept(s)
> here, giving the Ant task more responsibilty with
> regard to providing Ant (small 'r') resources in terms
> of Velocity Resources. This would allow the
> AnakiaTask v1.x to remain compatible with Ant 1.6
> (possibly/probably earlier versions but that's the
> version in the POM), while allowing other clients of
> the Anakia processor to be more agile, particularly by
> permitting the use of non-file resources.
>
> A directly related issue is that Ant 1.7.0 and beyond
> greatly extend Ant's own Resource concept such that
> adapters from Ant Resources to Velocity Resources, and
> related other adapters, should be fairly trivial to
> write: a 1.7-specific AnakiaTask could be quite an
> advance over the current implementation in terms of
> capability.
not that Anakia or Ant are my fortes, but this sounds like a good way to go.
> My initial investigation into the Anakia/Velocity code
> indicates that there may be some Velocity-specific
> idiosyncrasies with regard to ResourceLoader
> configuration, etc., so I have as yet been unable to
> determine the correct steps to take in modifying the
> Anakia processor class to use Resources. I present my
> case here hoping for some direction from experienced
> Velocity developers.
sure. got any specific questions here? or are you looking for a
general primer on Velocity ResourceLoaders?
> Regards,
> Matt
>
>
>
>
> ____________________________________________________________________________________
> Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
> http://autos.yahoo.com/carfinder/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org