You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2006/06/08 01:35:47 UTC
move velocity files into their own directory?
Anyone see any problems with me moving our velocity files into their own
directory. It's really messy with them just thrown about in the
WEB-INF/classes directory.
There are a couple options ...
1. put them in /WEB-INF/velocity/*. This means they would be picked up
by the WebappResourceLoader which I will tweak to make this work.
2. put them in /WEB-INF/classes/velocity/*. They continue to work out
of the ClasspathResourceLoader, but we have to modify the
velocity.properties to update it with new paths to all the .vm files.
I think I prefer option #1 the best. The other benefit is that the
webapp resource loader is the first RL in the list, so that means that
these files will be found and used without having to consult the other
RLs. Technically that should mean this is faster.
Anyone see any problems with this? Alternate options/opinions?
-- Allen
Re: move velocity files into their own directory?
Posted by Allen Gilliland <al...@sun.com>.
k ... i committed this under the pretense that silence = consent.
there are still a few files left straggling though ...
WEB-INF/classes/themes/css.vm
WEB-INF/classes/themes/day.vm
WEB-INF/classes/themes/new_page.vm
as far as i can tell, the day.vm and new-page.vm are not used and can be
removed. anyone want to confirm that?
sadly, the css.vm is directly referenced in the "basic" theme, so we
can't move it.
-- Allen
Allen Gilliland wrote:
>
>
> Dave Johnson wrote:
>> On 6/7/06, Allen Gilliland <al...@sun.com> wrote:
>>> Anyone see any problems with me moving our velocity files into their own
>>> directory. It's really messy with them just thrown about in the
>>> WEB-INF/classes directory.
>>> There are a couple options ...
>>> 1. put them in /WEB-INF/velocity/*. This means they would be picked up
>>> by the WebappResourceLoader which I will tweak to make this work.
>>> 2. put them in /WEB-INF/classes/velocity/*. They continue to work out
>>> of the ClasspathResourceLoader, but we have to modify the
>>> velocity.properties to update it with new paths to all the .vm files.
>>>
>>> I think I prefer option #1 the best. The other benefit is that the
>>> webapp resource loader is the first RL in the list, so that means that
>>> these files will be found and used without having to consult the other
>>> RLs. Technically that should mean this is faster.
>>>
>>> Anyone see any problems with this? Alternate options/opinions?
>>
>> Good idea. Option #1 does sound like the best approach.
>>
>> Should they all be dumped into one directory or should we further
>> segregate them into macro library files, feed templates and other
>> templates?
>
> naw, i was going to leave the feed templates and other special stuff in
> their own directories. i just wanted to get the all the .vm files in
> the classes directory moved into a directory so they are easier to see
> and aren't mixed in with other config files, etc.
>
> we can set it up however we want. we could use subdirectories for the
> feeds, that might be nice, like /WEB-INF/velocity/feeds/(atom,rss).vm.
>
> -- Allen
>
>
>>
>> - Dave
Re: move velocity files into their own directory?
Posted by Allen Gilliland <al...@sun.com>.
Dave Johnson wrote:
> On 6/7/06, Allen Gilliland <al...@sun.com> wrote:
>> Anyone see any problems with me moving our velocity files into their own
>> directory. It's really messy with them just thrown about in the
>> WEB-INF/classes directory.
>> There are a couple options ...
>> 1. put them in /WEB-INF/velocity/*. This means they would be picked up
>> by the WebappResourceLoader which I will tweak to make this work.
>> 2. put them in /WEB-INF/classes/velocity/*. They continue to work out
>> of the ClasspathResourceLoader, but we have to modify the
>> velocity.properties to update it with new paths to all the .vm files.
>>
>> I think I prefer option #1 the best. The other benefit is that the
>> webapp resource loader is the first RL in the list, so that means that
>> these files will be found and used without having to consult the other
>> RLs. Technically that should mean this is faster.
>>
>> Anyone see any problems with this? Alternate options/opinions?
>
> Good idea. Option #1 does sound like the best approach.
>
> Should they all be dumped into one directory or should we further
> segregate them into macro library files, feed templates and other
> templates?
naw, i was going to leave the feed templates and other special stuff in
their own directories. i just wanted to get the all the .vm files in
the classes directory moved into a directory so they are easier to see
and aren't mixed in with other config files, etc.
we can set it up however we want. we could use subdirectories for the
feeds, that might be nice, like /WEB-INF/velocity/feeds/(atom,rss).vm.
-- Allen
>
> - Dave
Re: move velocity files into their own directory?
Posted by Dave Johnson <sn...@gmail.com>.
On 6/7/06, Allen Gilliland <al...@sun.com> wrote:
> Anyone see any problems with me moving our velocity files into their own
> directory. It's really messy with them just thrown about in the
> WEB-INF/classes directory.
> There are a couple options ...
> 1. put them in /WEB-INF/velocity/*. This means they would be picked up
> by the WebappResourceLoader which I will tweak to make this work.
> 2. put them in /WEB-INF/classes/velocity/*. They continue to work out
> of the ClasspathResourceLoader, but we have to modify the
> velocity.properties to update it with new paths to all the .vm files.
>
> I think I prefer option #1 the best. The other benefit is that the
> webapp resource loader is the first RL in the list, so that means that
> these files will be found and used without having to consult the other
> RLs. Technically that should mean this is faster.
>
> Anyone see any problems with this? Alternate options/opinions?
Good idea. Option #1 does sound like the best approach.
Should they all be dumped into one directory or should we further
segregate them into macro library files, feed templates and other
templates?
- Dave