Moshe Yudkowsky wrote:
Ross,
Thanks again for your quick help. We've got a little bit of cross-talk
going on right now as our emails cross each other.
First of all, I'm up and running. (I'm debugging the placement of raw
content -- raw-content-dir doesn't seem to work as I'd expect -- and
I'll have everything in hand.)
Did you see http://forrest.apache.org/docs_0_70/upgrading_07.html#raw
I have no idea what gives you this impression that is the location for
Forrest skins, not project skins.
In $FORREST_HOME/main/forrest.build.xml, there's a comment on line 102:
"people should use forrest.properties to override following defaults."
The file then goes on to define forrest.skins-dir and forrest.plugins-dir.
Yes, meaning that devs shouldn't change values in the build file since
they can be configured in forrest.properties. It doesn't say anything
about not using project.skins-dir.
The experience I've been having indicates to me project.skins-dir is
being ignored in favor of forrest.skins-dir. When I changed
forrest.skins-dir in forrest.properties, my system built itself as
expected. When I tried using project.skins-dir, my skins were not found.
No, the process is that it checks in the forrest.skins-dir and then in
the project.skins-dir. Since you are using your own skin it obviously
won't find it in the forrest dir. Threfore your settings of the
project.skins-dir propery must be incorrect otherwise it would find it
(as it does for all users since 0.7 was released).
Furthermore, as I just noted, a "mkdir test; cd test; forrest seed;
forrest" fails as the system attempts to place plugins into the
$FORREST_HOME file system.
Yes, this is a known issue, that is why you can configure the location
of the plugins directory using forrest.properties. However, you
mentioned you still got an error, but you didn;t say what that error was.
Please let me know if there are any other tests I should be running, or
if you'd like me to send you forrest.properties files (directly).
Having the props file may help, but please send it to list (there
shouldn't be anything private in there, but check anyway). We don't
encourage private communications as the problem and solution will then
be lost from the archives.
This *may* be an artifact of not accepting anything but relative path
names, now that I think of it. If what I'm saying here is complete
bilge, please let me know and I'll see if that's really the case.
It does accept relative paths - relative to the project root.
Ross
