Quoting Brent Owens <brentowens@anonymised.com>:
I believe the GEOSERVER_DATA_DIR is part of the web.xml file, and is
only effective if the user builds their own war.
I started a better way for this but never quite finished it. My plan
was to have an environmental variable of the same name that you could
set on linux or windows. The embedded jetty start up would look for it
and pass it in (gs will pick up the var if it's passed in). I wrote
most of the code to do it, but I didn't have time to get it working
_exactly_ how I wanted, so I never committed. I can see if the code is
still somewhere, though i also could do it again...
And the user doesn't have to build their own war, they just have to
modify the web.xml of the exploded war.
Correct me if I am
wrong. I would like to see a completely separate directory that is
not
installed over, the idea behind the GEOSERVER_DATA_DIR.
Right now the upgrade versions come in: WAR form, windows installer,
and
binary tar.gz package.
Yeah, I don't like the idea of 8 potential downloads on sf. I know
upgrade vs. non is pretty straight forward, but still, I like
eliminating options as much as possible.
I think Justin got the mapbuilder stuff working by not using the data
dir but using the local geoserver dir.
Yeah, I don't think it's possible to use data dir with mapbuilder. Not
sure how to handle that... could advise that the geoserver mapbuilder
is demo only, and if you're building your own app to put it in its own
war. The auto generation stuff should still work and indeed improve
each version, just advice users to not touch any of it, or it will be
lost.
Styles:
Yeh we probably don't want to destroy their styles. Although I think
they would create their own files and we wouldn't have to worry about
overwriting them.
On second thought if you go this route (which i'm not yet sold on, I
prefer improving data dir to meet the needs, instead of more downloads)
leave the whole 'data' directory. The point of that directory is
'stuff that is your install'. Like plug-ins for validation, one could
change those. And then things that we may add in the future as well...
Another thought is you could have at least the windows installer detect
a previously installed geoserver (easy to do, check the registry), and
ask the user if they want to save their old dir (could even check
geoserver_data_dir environment variable, and even if it's changed from
the default in the current web.xml - do super smart stuff, only asking
to save old dir if they haven't defined a new one, and in the process
educate them that they can define a data dir and avoid this question in
the future).
Chris
We can try releasing the upgrades (with a warning) this release and
see
how it goes.Brent Owens
TOPPChris Holmes wrote:
>Quoting Brent Owens <brentowens@anonymised.com>:
>
>
>
>>I changed the ant script to now build the nsi windows install file,
>>so
>>it is one less step we have to do when releasing.
>>It also created the upgrade version of a GeoServer install that
>>contains
>>everything but the WEB-INF/data/featureTypes content and the
>>services.xml and catalog.xml files. Hopefully this will allow users
>>to
>>install over their existing geoserver install and not lose their
>>settings.
>>
>>
>David actually built the GEOSERVER_DATA_DIR to do exactly that. You
>just define what your data directory is, and point the new install
at
>it, and don't have to worry about anything overwriting. In general
I
>like that approach better, so we don't have to provide separate
upgrade
>and non-upgrade versions. Is the upgrade one just going to be a
zip?
>Or an installer and a war and all that?
>
>There's also the styles directory, and I'm not sure if we need to
save
>that for users. For the data_dir stuff we do the whole data
directory,
>plus the catalog and services files.
>
>The one downside of the data_dir is that the mapbuilder stuff
doesn't
>work right with it. I'd prefer to just resolve that, though I've
not
>thought at all how to do so/if it's possible.
>
>
>
>>Are there any other files that are missing that I should have
removed
>>from the update version?
>>
>>I will update the release guide docs to reflect the changes.
>>
>>--
>>Brent Owens
>>TOPP
>>
>>
>>
>
>
>
>
>----------------------------------------------------------
>This mail sent through IMP: https://webmail.limegroup.com/
>
>
>
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/