> Can you remind us what the thread was about, preferably by summarising > the outstanding issues, or if that is too much work by providing a link > to the archives.
This is the original thread: http://marc.theaimsgroup.com/?t=110172152700001&r=1&w=2 with this being the original idea > Currently we have (C = configuration) : > > my-project/ > status.xml > forrest.properties (C) > src/ > documentation/ > skinconf.xml (C) > content/ > xdocs/ > site.xml (C) > tabs.xml (C) > classes/ > CatalogManager.properties (C) > resources/ > images/ > **.gif||jpg||... > > > Assumptions on how it should change: > > 1 - shallower dir structure > 2 - single dir for configuration > 3 - single dir for content > 4 - content dir contains only content, not configuration > 5 - no Forrest content outside of the conf and content dirs > > my-project/ > documentation/ > conf/ > forrest.properties > skinconf.xml > site.xml > tabs.xml > content/ > status.xml > ** all other content > > Notes: > > a - the /documentation dir can be anywhere: when Forrest first starts > it shall search for some predefined directories, and then in the > whole directory structure till it finds forrest.properties. > Then it caches it in the user dir and uses that to resolve all > other directories. > > b - status.xml will become like all other files, and will not be > anymore in a fixed position, as it will match on DTD- > > Now here is a different layout (we may as well decide a mix between this > and the previous one): > > my-project/ > forrest.xml > > documentation/ > status.xml > ** all other content > > FORREST-INF/ > skinconf.xml > site.xml > tabs.xml > > Notes: > > c - forrest.properties is renamed forrest.xml and uses xml; this > ensures that the paths do not contain whitespace at the end. > Furthermore having forrest in the base dir is a clear sign > the the documentation of the project is done with Forrest, and > that it's to be launched in that dir. > This file must only contain the link to the *main* Forrest dir > and the output dir. > > d - The configuration is kept inside the documentation dir under > FORREST-INF/, in a similar way to WEB-INF. This shortens the > path to the documentation. > > This configuration has the advantage that the whole documentation is in > one directory, and can be used also without forrest.xml. > Let me enhance the discussion by talking about configuration. > > - O - > > We now have configuration in many different places, and I want to see it > reduced. > > Furthermore, there have been requests to make our sitewide configuration > more pinpointed to single dirs or files (special headers), and > documentation set joins (multiproject docs). with this being a possible outcome after considering the comments > my-project/ > forrest.xml > > content/ > status.xml > ** all other content > > FORREST-INF/ > skinconf.xml > site.xml > tabs.xml In fact having re-read all of this I'd go another step and suggest something like this (* = my reasons for this). my-project/ forrest.properties to become forrest-properties.xml *you know what is is right away all other config files *why not keep them in the root much easier to find. no clutter to be expected because there are not so many CatalogManager.properties *why have a subdir just for one file? content/ status.xml site.xml tabs.xml former content of xdocs here and in subdirs if required content-untranslated/ images, binaries ... * I'd rather not have untranslated content in the resources tree as Nicola proposed (though I understand the logic behind it) because it is much harder to create references to files if their structure of subdirs does not start from the same level as the subdirs in content. In fact from a users perspective I'd even suggest to have raw content in the content dir for easier management, but I'm not sure that is possible. resources/ schema/ stylesheets/ * the following changes are inspired by the other thread (on change in terminology) static-output/ instead of build/site/ * say what it is server-space/ instead of build/ * to mark it as server workspace tmp/ instead of build/tmp/ * if this is really server only otherwise move it up one level webapp/ instead of build/webapp/ * perhaps we can do without this and move the files one up? wdyt? -- Ferdinand Soethe
