I think we should keep build/ as top-level because that is most common in cocoon related projects. Everything that you now describe is part of some kind of build.
I will make this point one last time and then keep quiet about it.
I'd rather you didn't keep quiet. Your opinion is critical in this.
This whole discussion was started because I wanted Forrest to become more transparent for new people beyond the sworn in community. And this goal is sometimes incompatible with making 'cocoonies' feel right at home.
But we/you need to make up our mind about that. And if you decide to stick to the technical naming we have now, we won't be able to explain structure to normal people (or train it) and so I'd start working on a gui interface that hides all this.
Who currently uses Forrest? Who will Forrest be used by in the future?
and most importantly:
Who is Forrest aimed at?
I ask these questions because what Ferdinand is proposing relies on us being able to answer these questions. He is proposing considerable changes in the names of important files, directory structures and concepts in order to make Forrest more understandable for a, as yet, unidentified, end user.
Right now, in my view, Forrest does not want to attract end users that are not comfortable with XML, CSS, XSLT and Cocoon Pipelines. In my view we should be improving our docs from a *technical* perspective rather than a *user* perspective. We should be making it really easy for people to build new plugins and skins. We should be making it really easy for technical users to come along and enhance the Forrest application.
Changing our terminology to one that is not appropriate for technical users, most likely coming from a Cocoon background or from an XML/XSLT background, may have actually make it *harder* for the very users we are trying to attract (IMHO).
I do understand what Ferdinand is trying to do, and I agree that making Forrest more accessible to non-technical end users is very important. However, I'm not convinced the approach is correct.
I would prefer to see (non-technical) end users supported by a set of tools for configuring Forrest, preferably with a GUI interface, but at the very least by ant scripts that will ask the user questions and configure the system accordingly.
For example, doing 'forrest seed' should ask what the site name is, what skin should be used, what plugins will be required and so on. The end result will be a seed site that doesn't need customising through the editing of config files and so the (non-technical) user doesn't need to know anything about them. Consequently we can keep their locations and names familiar to the technical user.
I'm +1 on name changes that make it easier to document (non-technical) end-user interfaces to the application. But I'm -1 on changing things that the (non-technical) user should have no need to see. I'd rather see the effort go into writing helper applications/scripts that hide the complexities of Forrest from such users whilst still keeping the underlying design familiar to out technical users.
Writing Ant scripts is surprisingly easy once there are a set of examples to follow. Perhaps effort should be put into user focused scripts rather than complex name changes that will resonate through all our existing code and documentation.
Ross
