On 6/1/07, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Nathan Bubna <[EMAIL PROTECTED]> wrote: > On 6/1/07, Matt Benson <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
