Conf need to be self contained, and not chris's own work environment. The first time user should have a bunch of shapefiles that the can view right from the git go
It would be even better if the shapefiles matched the cite tests so they could test their install right from the start.
CodeHaus Comment From: jgarnett - Time: Mon, 19 Jan 2004 22:47:33 -0600
<p>Have update the conf on head, to try and have something that works:</p>
<p>A few comments as I tried to work on this:</p>
<p>1) Very Inconvient to specify a DataStore for each shapefile (can we ever move to a DataStore defined as a directory of shapefiles?)</p>
<p>2) Shapefile for cite data (currently uses cite_posgis)</p>
<p>3) info.xml <attributes/> - is this still used or is it completely replaced by the parsing of the schema.xml file></p>
<p>4) there are nice metadata.html files next to the cite featureTypes can
we grab these and place in the Geotools2 metadata classes?</p>
CodeHaus Comment From: cholmes - Time: Tue, 20 Jan 2004 10:35:41 -0600
<p>Thanks for working on it. As for my responses:</p>
<p>1. I agree, my thought was that we could do something like datastore.id=local.shape in the info.xml file, which would indicate that the file named in the name element of the info.xml file in the same directory should be used. I haven't thought through the implementation of this, but there's always a way, no? I also wouldn't be against the directory of shapefiles, but think this would make more sense with our current config hierarchy.</p>
<p>2. I'd like it. I'm not doing it. If you get some interns give them the task <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> </p>
<p>3. I'm pretty positive it's completely replaced. Ask David to be sure. But as far as I know the functionality has been replaced with the schema stuff.</p>
<p>4. Those metadata files are not for cite. I'm not sure how the geotools stuff references them, but yeah, you can use them or modify them. They probably should actually talk about the sample features though. Eventually I'd like to roll the lucene backend of the zserver module into geotools. This is a major project, so for now just do what you like.</p>
CodeHaus Comment From: jgarnett - Time: Tue, 10 Feb 2004 17:31:29 -0600
<p>cholmes Hey, David wanted me to jump on with my feelings on having all the cite featureTypes in conf by default.
dzwiers we were talking about cite test
cholmes I don't want them in the main conf directory.
dzwiers when they go out i would rather not have users in the web app
cholmes I'd like the full configuration in a zipped file that can be unzipped, creating the full conf/ directory of all the cite types.
dzwiers wanted to give a binary with cite shape files
cholmes users in the web app?
dzwiers or, the web server directories
jgarnett Okay: I think I get it? We are talking about what the initial conf directory should look like?
cholmes I don't like all the cite data in there because it's a bunch of featureTypes and they are all meaningless.
jgarnett I have two thoughs on this one, I would like to have shapefiles available for developers to test with, but I would also like something nice for users to start out with.
jgarnett I think we have two different audiences.
cholmes If a user wants to check out geoserver working and is looking at cite Other then they see one feature.
jgarnett Chris we have talked about making a user war have we not?
cholmes Developers can easily replace their conf directory with the tarred up configuration.
jgarnett Can we set that one up with nice data (or empty data), and leave the CVS conf direct with cite shapefiles?
dzwiers well ... we could have the build script do that
cholmes That configuration will have the services.xml and catalog.xml and all the featureType directories and file.
jgarnett That is switch it around
jgarnett David we could also have a ui action that lets you choose a precanned conf structure of misc
jgarnett (but I though we were trying to cut down for the end user experence?
dzwiers so you guys only want bcroads in the user binary?
jgarnett You are right david we need to think on this one
cholmes I could maybe be convinced to switch it around.
jgarnett Chris, we are planning to write user documentation for the configuration and validation modules
dzwiers i understand the dev side wanting some cite configs, but what should a user already have the first time they see it
cholmes I'd like bc_roads and a few other nice shapefiles that make pretty pictures, and return a decent amount of gml.
jgarnett We want some test data that agrees with the documentaiton to be included in the war for the user (chris are we still making a war for the user?)
dzwiers ie. how do we tell them they are working correctly
cholmes Yes, we're still making a war file.
cholmes By telling them to do a getCaps, a getFeature, and a getMap.
cholmes Which is what I do now.
cholmes If those work then they should be good to go.
jgarnett Can we make buttons on the testServlet page for those requests?
cholmes Running full cite test suite is extreme overkill.
cholmes It takes like an hour.
dzwiers agreed on overkill, just wasn't convinced that you had a large enough min set
jgarnett Okay, I would still like shapefiles for cite so that developers can test with less overhead. Cause right now only you and david test. I want all developers (like me) to test
cholmes I'm fine with a larger set, I just want the data to <em>mean</em> something.
dzwiers can make a set of ten calls or something like that for bc-roads
cholmes I would love shapefiles for cite too.
jgarnett Okay, chris I would like to add david shae's bc lake data to the user set (we will use it for our validation docs)
cholmes We also could do unit tests, and/or use cactus or something.
cholmes That's totally fine.
dzwiers i think i can get them to work about the same as postgis for 1.2beta
jgarnett translate cactus, is that junit over http
cholmes Ideally I'd like maybe 4 or 5 sample featureTypes.
dzwiers dave's data still needs to be set-up to read correctly (havn't gotten to that yet)
jgarnett So to repeat : we have two issues. User war with a conf based on docs. Developer conf - with cite shapefiles
cholmes cactus is junit for servlets (among other things)
jgarnett I will capture this irc, for the conf jira task
cholmes It would be nice to have featureTypes for each of the datastores, with table creation scripts for the databases...
jgarnett Idea: are we ever going to fix tomcat? Or are we going to go with war+instructions?
cholmes Yes, we are going to fix tomcat.
jgarnett Chris do you mean for the user or developer
cholmes for the user.
jgarnett chris: fixing tomcat looks tough
jgarnett Right now it looks like it is setup for testing, not for a user
jgarnett David - you looked into this can you chime in?
cholmes Ok, that yes is provisional - for a user we want the war for 1.2.0
cholmes Eventually I would like to get the embedded tomcat working for an end user.
cholmes But we can put that task months down the line.
dzwiers appears that the web.xml file is not read, which has a alot of struts stuff
jgarnett Okay - good
jgarnett we will knock it out of scope then
cholmes Totally fine.
cholmes It's just the goal which I'm eventually striving towards - like an exe where you don't have to download anything but java, and can just get up and running.
jgarnett Chris can we make different ant targets: test-devel and test-user? That produce different conf directories in the war?
cholmes Perhaps even bundling a jre eventually.
jgarnett How about a one-click installer <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
cholmes Or at least a few click installer - I like resin on windows - just set the default port and then you can go.
jgarnett Doing that with a separate Tomcat may be easier
jgarnett That is the oneclick installer may be easier than EmbeddedTomcat
jgarnett chris: comment on test-devel vs test-user?
cholmes yeah, that's fine.
jgarnett Can this resolve our *conf*lict of interest <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
cholmes Or maybe call it 'test cite'.
dzwiers i think i got what you guys want
jgarnett That would be smart chris
jgarnett Yeah this is a good direction everyone.
jgarnett dzwiers: <a href="https://jira.codehaus.org/browse/GEOS-93" title="How to change Config developers guide" class="issue-link" data-issue-key="GEOS-93"><del>GEOS-93</del></a> is calling you <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
cholmes And I think ideally 'test cite' takes a parameter -Dtest.type='postgis' or 'shapefile' or 'oracle' eventually.
cholmes Shapefile by default if we get that passing all cite tests.
dzwiers good idea chris</p>
CodeHaus Comment From: dzwiers - Time: Wed, 11 Feb 2004 13:48:47 -0600
<p>Wanted to log the plans. I intend to have three build targets:</p>
<p>1) a WAR file for an end user.
2) a SRC distribution for developers.
3) a test build which generates and places a WAR for a developer testing.</p>
CodeHaus Comment From: dzwiers - Time: Wed, 11 Feb 2004 20:06:08 -0600
<p>new build target - release-binary</p>
<p>uses a bundled conf in the misc directory</p>