Andrea Aime wrote:
The error messages I reported on the list were literally about geoserver having no configuration.
Can you refresh my memory? This kind of error should not happen.
It is on that page still as an example of what to expect - something in the web module would fail when it did not have a configuraiton.
I found that my home machine does not have a geoserver development environment on it so I will be able to check this one over the next couple of days.
Hum, this is unfair. It's a reasonable quickstart looking at Geoserver
as an application. But you're right, if we want to make Geoserver a
framework, in the long run, we'll need to treat it as such and so
include directions to build javadocs and the like.
I am setting up some new developers for geoserver life and happiness and at this stage in the experience I wanted instructions to point them towards (not explainations and alternatives). Since I have the need I am updating the page before hand.
Yet, until modularization is completed (UI is missing), and the new
dispatcher is deployed onto all services, and the catalog is replaced,
touting Geoserver as a framework is giving false hopes to the reader.
Indeed. My focus is literally on starting off new geoserver developers. I would like more of them it is true; and we have this whimsical notion that documentation will help with that. Paul Ramsey has a blog on the topic somewhere ...
It appears we need to provide instructions for checking out the default configuration as part of this page (now that the minimal configuration is actually an empty configuration).
Well... the default config is long gone. If you're messing with Geoserver and have few bandwith, use the emtpy configuration and add your local data to preview something. If you have enough bandwith, check out the full stuff (not trunk/geoserver, but trunk/) and play with release data. The default config just added mantainance and size
overhead to the configuration set.
Understood; and this page was the one I figured was most effected by the configuration stuff. The new instructions did not say how to check out a configuration from svn - I have added it in now. I did use release as an example but it sounds like that contains too mcuh stuff?
Is there a small configuration that would be better to choose - give my goal of setting up someone quickly.
Q: Is it really worth making the default configuration empty? We could just include states.shp and be done with it? Letting developers check out and get visual confirmation is what we are after and putting off talking about configuration until later would be worth it.
I disagree. The emtpy configuration is your starter point for
developing a new geoserver based application, and contains just
enough information to get Geoserver started and fiddle with your
local data. If you're checking out Geoserver sources you're also
supposed to be able and use it, so adding a local shapefile should be
a matter of a couple of minutes.
Okay; so it is worth it making the default configuration empty then.
Jody
