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