[Geoserver-devel] New client code for GeoWebCache

Hello folks,

I have this pending pull request for the GeoWebCache project:

https://github.com/GeoWebCache/geowebcache/pull/62

Gabriel has been helping me push my work back into GeoWebCache and it’s all ready-to-go from the GeoWebCache project’s point of view, but I’m running into trouble with the GeoServer integration part.

The problem is GeoServer grabs the JAR’s for GeoWebCache but any static HTML files were copied and duplicated between the projects. This was OK when it was only a couple of HTML files that weren’t going to change much, but now the UI improvements are a much larger code base. There are only about 5 new js and HTML files with a few CSS and images, but ExtJS 4 is bundled with it as well.

I’ve had a go at an approach where GeoServer can grab the static HTML client files through maven dependencies using the WAR merging technique where maven will merge one war into another during the build. This has a limitation though for the GeoWebCache project: it interferes with eclipse debugging because the static html resources aren’t in the same web project anymore so they aren’t available at runtime. I could probably tweak the project settings in eclipse to add the static resource path but that means there is a custom dev environment setup step beyond mvn eclipse:eclipse - which I don’t want.

So at the moment I can only think of the following options:

1: Duplicate client code in GeoServer - not so good as there will be checked-in code that shouldn’t be changed in the GeoServer code base - because it’s in the GeoWebCache code base.

2: GeoServer doesn’t get the new HTML client improvements. It does get the REST interface improvements and can create jobs as that’s part of the original UI that’s embedded in the JAR’s. It could also be added to a GeoServer install easily, or installed separately and pointed at it.

3: Separate out the HTML client into its own project. It could operate as a standalone client – it’s been designed to only interact with GWC through the REST interface. This is almost the case now as the separated HTML code on my local box is in a separate project under the GWC project and builds its own WAR (probably should be a zip instead I guess… there is no Java webapp component in it) - the GeoWebCache WAR would still build with the client integrated but you’d need to manually plug it in for debugging.

4: Someone out there knows MVN better than me and knows how to tweak it so everyone wins.

Is there a way to handle this that the GeoServer community would prefer / accept or maybe a suggestion that would be better? Maybe you guys don’t really want the improved client code only the improved REST bits so option 2 is better? At this point it’s looking like option 3 is the best one if we can’t come up with an option 4.

Regards,

Jim Groffen.

LISAsoft

Level 1, 30 Currie St

Adelaide SA 5000 Australia

PO Box 8118 Adelaide SA 5001

Hi Jim,

please the the comment on the gwc issue <https://github.com/GeoWebCache/geowebcache/pull/62#issuecomment-2578071>

I think the way to go would be making it so that those static resources are served through the /web gwc endpoint.

Hope that helps,
Gabriel

On Mon, Oct 31, 2011 at 2:38 AM, Jim Groffen <jim.groffen@anonymised.com> wrote:

Hello folks,

I have this pending pull request for the GeoWebCache project:

https://github.com/GeoWebCache/geowebcache/pull/62

Gabriel has been helping me push my work back into GeoWebCache and it’s all ready-to-go from the GeoWebCache project’s point of view, but I’m running into trouble with the GeoServer integration part.

The problem is GeoServer grabs the JAR’s for GeoWebCache but any static HTML files were copied and duplicated between the projects. This was OK when it was only a couple of HTML files that weren’t going to change much, but now the UI improvements are a much larger code base. There are only about 5 new js and HTML files with a few CSS and images, but ExtJS 4 is bundled with it as well.

I’ve had a go at an approach where GeoServer can grab the static HTML client files through maven dependencies using the WAR merging technique where maven will merge one war into another during the build. This has a limitation though for the GeoWebCache project: it interferes with eclipse debugging because the static html resources aren’t in the same web project anymore so they aren’t available at runtime. I could probably tweak the project settings in eclipse to add the static resource path but that means there is a custom dev environment setup step beyond mvn eclipse:eclipse - which I don’t want.

So at the moment I can only think of the following options:

1: Duplicate client code in GeoServer - not so good as there will be checked-in code that shouldn’t be changed in the GeoServer code base - because it’s in the GeoWebCache code base.

2: GeoServer doesn’t get the new HTML client improvements. It does get the REST interface improvements and can create jobs as that’s part of the original UI that’s embedded in the JAR’s. It could also be added to a GeoServer install easily, or installed separately and pointed at it.

3: Separate out the HTML client into its own project. It could operate as a standalone client – it’s been designed to only interact with GWC through the REST interface. This is almost the case now as the separated HTML code on my local box is in a separate project under the GWC project and builds its own WAR (probably should be a zip instead I guess… there is no Java webapp component in it) - the GeoWebCache WAR would still build with the client integrated but you’d need to manually plug it in for debugging.

4: Someone out there knows MVN better than me and knows how to tweak it so everyone wins.

Is there a way to handle this that the GeoServer community would prefer / accept or maybe a suggestion that would be better? Maybe you guys don’t really want the improved client code only the improved REST bits so option 2 is better? At this point it’s looking like option 3 is the best one if we can’t come up with an option 4.

Regards,

Jim Groffen.

LISAsoft

Level 1, 30 Currie St

Adelaide SA 5000 Australia

PO Box 8118 Adelaide SA 5001


The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.


Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Hello Gabriel,

That could work as a fouth option, that way I can bundle the resources into a JAR…

Thanks Gabriel, I’ll try it out.

Jim Grorffen.

···

From: groldan@…13… [mailto:groldan@…13…] On Behalf Of Gabriel Roldan
Sent: Tuesday, 1 November 2011 2:06 AM
To: Jim Groffen
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: New client code for GeoWebCache

Hi Jim,

please the the comment on the gwc issue <https://github.com/GeoWebCache/geowebcache/pull/62#issuecomment-2578071>

I think the way to go would be making it so that those static resources are served through the /web gwc endpoint.

Hope that helps,

Gabriel

On Mon, Oct 31, 2011 at 2:38 AM, Jim Groffen <jim.groffen@…1052…> wrote:

Hello folks,

I have this pending pull request for the GeoWebCache project:

https://github.com/GeoWebCache/geowebcache/pull/62

Gabriel has been helping me push my work back into GeoWebCache and it’s all ready-to-go from the GeoWebCache project’s point of view, but I’m running into trouble with the GeoServer integration part.

The problem is GeoServer grabs the JAR’s for GeoWebCache but any static HTML files were copied and duplicated between the projects. This was OK when it was only a couple of HTML files that weren’t going to change much, but now the UI improvements are a much larger code base. There are only about 5 new js and HTML files with a few CSS and images, but ExtJS 4 is bundled with it as well.

I’ve had a go at an approach where GeoServer can grab the static HTML client files through maven dependencies using the WAR merging technique where maven will merge one war into another during the build. This has a limitation though for the GeoWebCache project: it interferes with eclipse debugging because the static html resources aren’t in the same web project anymore so they aren’t available at runtime. I could probably tweak the project settings in eclipse to add the static resource path but that means there is a custom dev environment setup step beyond mvn eclipse:eclipse - which I don’t want.

So at the moment I can only think of the following options:

1: Duplicate client code in GeoServer - not so good as there will be checked-in code that shouldn’t be changed in the GeoServer code base - because it’s in the GeoWebCache code base.

2: GeoServer doesn’t get the new HTML client improvements. It does get the REST interface improvements and can create jobs as that’s part of the original UI that’s embedded in the JAR’s. It could also be added to a GeoServer install easily, or installed separately and pointed at it.

3: Separate out the HTML client into its own project. It could operate as a standalone client – it’s been designed to only interact with GWC through the REST interface. This is almost the case now as the separated HTML code on my local box is in a separate project under the GWC project and builds its own WAR (probably should be a zip instead I guess… there is no Java webapp component in it) - the GeoWebCache WAR would still build with the client integrated but you’d need to manually plug it in for debugging.

4: Someone out there knows MVN better than me and knows how to tweak it so everyone wins.

Is there a way to handle this that the GeoServer community would prefer / accept or maybe a suggestion that would be better? Maybe you guys don’t really want the improved client code only the improved REST bits so option 2 is better? At this point it’s looking like option 3 is the best one if we can’t come up with an option 4.

Regards,

Jim Groffen.

LISAsoft

Level 1, 30 Currie St

Adelaide SA 5000 Australia

PO Box 8118 Adelaide SA 5001


The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.


Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.