Hi all (hey Justin :-)),
I'd like to propose a configuration system change, where
configuration in this sentence is the data_dir zip
the maven_config plugin is unzipping into the web
module in order to provide one config or the other.
This way of doing things is hard to maintain, for each
modification you have to unpack zip, modify, re-pack.
My proposal is:
* have configurations be stored, unpacked, in their own
modules, and have them be proper data dir (that is, with
config and catalog inside, not destined to be put in
web-inf). That is, have:
geoserver/
config/
minimal/
basic/
release/
citeWms/
citeWfs/
* have the config plugin copy one of them into the
web module (quite similar to what it's doing now,
just that it's copying stuff from unpacked)
* btw, I called them modules, but I'm not meaning
these are real maven modules... just directories.
Well, in fact I would prefer to have something that
add the data dir in just in the war, without touching
the web module sources, but I guess that would make
things more complicated.
The advantages of the above proposal would be
that's much easier to change the configurations, the
disadvantage is that we do have more binary stuff in
svn... well, one more reason to keep configs small, no?
Hi all (hey Justin :-)),
I'd like to propose a configuration system change, where
configuration in this sentence is the data_dir zip
the maven_config plugin is unzipping into the web
module in order to provide one config or the other.
Oh hum, this may not be super-clear.
Currently the web module uses a plugin that takes
a zip file (release.zip, basic.zip, and so on) and
unpacks it into the web module in order to create
a configured data dir in it.
In order to change config, you have to run a
mvn clean install -DconfigId=<configId>
where <configId> is xxx if you want to unpack xxx.zip.
Andrea I think the current solution is there in order to save on svn space - I understand that the zip files were committed lately (not sure this was in the plan).
So by all means if we are going to include sample code in svn then we can make modules for it; if we are isolating sample configurations as a seperate download the existing set up makes sense.
Jody
Andrea Aime ha scritto:
Hi all (hey Justin :-)),
I'd like to propose a configuration system change, where
configuration in this sentence is the data_dir zip
the maven_config plugin is unzipping into the web
module in order to provide one config or the other.
Oh hum, this may not be super-clear.
Currently the web module uses a plugin that takes
a zip file (release.zip, basic.zip, and so on) and
unpacks it into the web module in order to create
a configured data dir in it.
In order to change config, you have to run a
mvn clean install -DconfigId=<configId>
where <configId> is xxx if you want to unpack xxx.zip.
Andrea I think the current solution is there in order to save on svn space - I understand that the zip files were committed lately (not sure this was in the plan).
So by all means if we are going to include sample code in svn then we can make modules for it; if we are isolating sample configurations as a seperate download the existing set up makes sense.
The existing setup is something that really makes me not want to
fiddle with configurations. I have better ways to spend my time than
unzip, change, zip, install, check. In my humble opinion making developers productive is more important than saving space.
I agree, the existing setup is not working for people, and those zip files are getting committed to the repository which defeats the purpose of them. The setup you are proposing Andrea is the same setup we had before the zip files. Like Jody says the reason we switched to zip files ( and this was really just my idea so I apologize for forcing it on people ) was because the amount of stuff getting committed into svn was getting out of hand.
I have said this before but when in South Africa i could literally not check out the GeoServer source. This is unnaccepptable imho. I also fear that now that we are doing coverages it will be even worse than before.
However, as one who is not really using it on a day to day basis my opinion doesn't weight as much as others. :).
-Justin
Andrea Aime wrote:
Jody Garnett ha scritto:
Andrea I think the current solution is there in order to save on svn space - I understand that the zip files were committed lately (not sure this was in the plan).
So by all means if we are going to include sample code in svn then we can make modules for it; if we are isolating sample configurations as a seperate download the existing set up makes sense.
The existing setup is something that really makes me not want to
fiddle with configurations. I have better ways to spend my time than
unzip, change, zip, install, check. In my humble opinion making developers productive is more important than saving space.