Hey chris, did not see you on irc today. I am reviewing documentation and trying to retire a few Jira tasks today.
I am afraid I have come a bit late to the conf directory, build.xml party - David build.xml file did let me switch between conf, and zipfiles based on command line parameters. (You mentioned fixing something that worked for me).
Chris Holmes wrote:
I've been thinking about this stuff as well, as I have been annoyed at the default conf stuff of late as well. I got David to do the initial change, as I wanted to be able to use my conf directory.
That is what I thought, my only concern is that you want to version control your conf directory on HEAD as well.
I like option c) the best, as I don't like not having a conf there at all, since it is harder for developers to build up their conf directory from scratch than to just modify one existing. I'm not sure I understand the difference between b) and c), as I don't know what developers documentation examples you're talking about.
This is that mythical documentation we have been talking about! The difference is that I would like *bad* examples as part of the developer conf directory: cite tests, invalid geometries for the validator to catch, and so on.
I did not want to annoy the user with this sort of thing, and I get the impression that you would also like to provide users with working "good" examples.
In my mind the easiest thing would be to make the developers docs use the user conf directory stuff. I don't see much of a reason for a developer to work with the cite test types, as I find them to be sort of bad examples, as they are all small and aren't real at all.
By developer I am refering to a GeoServer developer, making use of or extending the Framework. These are exactly the people I would like to be able to run the cite tests with little or know effort.
They're great for testing cite, but not much else, so I don't see any reason to have developers work against them.
See above - until we have more junit tests, I would like cite tests easily accessable. I remember back to December where I was stuck hacking on GeoServer with no way to tests, I don't want to put others in that situation.
If developers want the conf directory to be ignored then can't they just put in their own .cvsignore or something?
No .cvsignore is shared, and version controlled.
I'd like to keep the user's conf well tested, I don't like just having some zipped up directory that we put in the releases without completely testing it. In the past I've always had the conf directory be the one that developers and users both get, and I see no reason to change that.
It seems that cite shapefiles, and whatever invalid geometries I dream up for validation will be the major sticking points against having a shared conf directory.
It still think it would be easiest to have no conf in cvs, and have "conf" ignored by cvs, so all developers can unpack a conf directory and make use of it without having cvs clobber it every update. This would allow developers to work against the users conf, or the cite conf, or their own conf as needed.
What I don't think we should do is check in a conf on head that has ties to local databases at refractions or topp (which we have both done in the past).
The release build should always be done from a freshly checked out cvs directory structure, to ensure that nothing is out of sync at all, so I personally don't see a need for a zipped standard UserConf directory structure. It was actually never really my personal conf/ directory, that came with the admin tool merge; I've always made it an example file, with good comments, the datastores were just sample params for all available datastores, so that developers could modify them as they wanted to. So those were my plans.
Cool that is what we need to know - what your plans are.
So the open questions are:
- Should we use the same conf for both developers and users?
Pros: everybody tests together, Cons putting cite and other undesireable or even broken DataStores in the face of users.
What we need is:
- nail down the conf directory that ships with the user's war for documentation, screen snaps.
- nail down a conf directory for the developer documentation.
What I would like:
- conf not on head, so I put my own there and have test-ext suck it up
The only advantage to a ziped standard UserConf is consistency for documentation, and having a the application start up the first time they see it without any errors. I think the zip file is a bit much to maintain though, if it is broken out as a directory we can manage things a bit better using cvs.
Do they work with you guys? Is it ok if we add the conf directory back in? I'm fine with a few more sample featureTypes if that's what's needed for a well known conf structure to be the example in the developer docs.