Honestly I like the zip files for configuration, but all you are right ... if I need to change just a demo request which is an xml file of few bytes, I have to commit the zip file.
My only concern is, we used zip files to save space, now we are going back to a directory structure that stores the configuration directories uncopressed for every release. Personally I have no problems ... so if it is good for you, go ahed.
The zip files where mainly stored off svn to allow low bandwith regions
such as South Africa to checkout Geoserver anyways.
Having the zip in svn breaks that purpose.
The new layout allows people to checkout only the code and the minimal
configuration.
Hum, you're right in saying that if you need to checkout
the configs, you need more bandwith since stuff is not compressed.
Maybe we can use the build system to create the zip anyways and push
them onto some server? I think the nighly builds could do just that,
files created by Continuum are downloadable no?
Honestly I like the zip files for configuration, but all you are right ... if I need to change just a demo request which is an xml file of few bytes, I have to commit the zip file.
My only concern is, we used zip files to save space, now we are going back to a directory structure that stores the configuration directories uncopressed for every release. Personally I have no problems ... so if it is good for you, go ahed.
The zip files where mainly stored off svn to allow low bandwith regions
such as South Africa to checkout Geoserver anyways.
Having the zip in svn breaks that purpose.
The new layout allows people to checkout only the code and the minimal
configuration.
Hum, you're right in saying that if you need to checkout
the configs, you need more bandwith since stuff is not compressed.
Maybe we can use the build system to create the zip anyways and push
them onto some server? I think the nighly builds could do just that,
files created by Continuum are downloadable no?
Thats a good idea. Definitely doable.
I have also had this crazy idea to publish the configs as an actual maven artifact, so that we could use the normal maven dependency mechanism on them as opposed to the maven plugin we are using now. Would have to look into it a bit more though.
+1 (Although my brain is tired, I am in fact out of the pool)
Jody
Justin Deoliveira ha scritto:
Sounds like there is good agreement on this. Just a note can we give people a "get out of the pool" warning before anyone goes ahead and does this. Thanks.
Well since we had a GSIP for this, we need votes as well (the downside
of using a GSIP, as Jody warned). I prefer it like this anyways, since we're
going to change our directory tree layout.
So, so far we have positive votes from:
* aaime
* jdeolive
* bowens
+0 (since I've had problems tracking the evolution of the proposal and the relationship between the config change and this, which I'm still convinced are crossing over, so this is a useful stepping stone towards a more complete solution as far as I can see)
Rob
Jody Garnett wrote:
+1 (Although my brain is tired, I am in fact out of the pool)
Jody
Justin Deoliveira ha scritto:
Sounds like there is good agreement on this. Just a note can we give people a "get out of the pool" warning before anyone goes ahead and does this. Thanks.
Well since we had a GSIP for this, we need votes as well (the downside
of using a GSIP, as Jody warned). I prefer it like this anyways, since we're
going to change our directory tree layout.
So, so far we have positive votes from:
* aaime
* jdeolive
* bowens
+0 (since I've had problems tracking the evolution of the proposal and the relationship between the config change and this, which I'm still convinced are crossing over, so this is a useful stepping stone towards a more complete solution as far as I can see)
There is no crossing whatsoever. Before testing and shipping data dirs
where contained in zip files, after that they will be stored uncompressed in svn. We won't touch a single line of code.
It's just a matter of developer convenience for times when you need to
modify the configurations, either to add a sample request, or a sample
data, or changing the mapbuilder version we ship with, and so on.
That's all.