Add Graticule extension

[vuilleumierc]

No description provided.

[groldan]

This is looking really good so far. We would need to:

• Address the requested chages
• Add at least a test for GraticuleConfiguration, you can inspire in VectorTilesConfigurationTest for example.
• With datadir catalog backend: when creating a graticule store/layer in the webui, the wms layer preview fails with org.geoserver.platform.ServiceException: Could not find layer cite:Graticule_1_10. Works when the wms service is restarted. I'll look into it in case it's a problem with the event bus payload.
• With the pgconfig catalog backend it doesn't work. The GratitculeDataStoreFactory has a parameter of type ReferencedEnvelope that's encoded as JSON as bounds": {"crs": {"srs": "EPSG:4326", "wkt": null}, "coordinates": [-180.0, 180.0, -90.0, 90.0]}, but then it can't be decoded. I'll look into it.

[groldan]

Hi @vuilleumierc,

I just realized this is one of those cases where the geoserver plugin contains both the plugin's business classes as well as some wicket configuration extension.

The result is we have now the wms-extensions module adding transitive dependencies on gs-web-core and wicket-core:

[INFO] |  +- org.geoserver.community:gs-graticule:jar:2.25.0.1-CLOUD:compile
[INFO] |  |  +- org.apache.wicket:wicket-core:jar:7.18.0:compile
[INFO] |  |  |  +- org.apache.wicket:wicket-request:jar:7.18.0:compile
[INFO] |  |  |  \- org.apache.wicket:wicket-util:jar:7.18.0:compile
[INFO] |  |  \- org.geoserver.web:gs-web-core:jar:2.25.0.1-CLOUD:compile
[INFO] |  |     +- org.apache.wicket:wicket-extensions:jar:7.18.0:compile
[INFO] |  |     +- org.wicketstuff:wicketstuff-select2:jar:7.18.0:compile
[INFO] |  |     |  \- de.agilecoders.wicket.webjars:wicket-webjars:jar:0.5.3:compile
[INFO] |  |     +- com.github.svenmeier.wicket-dnd:wicket-dnd:jar:0.7.3:compile
[INFO] |  |     \- joda-time:joda-time:jar:2.10.13:compile

The problem is, though that's expected for the webui, it's not for wms, rest, and gwc. I.e. we don't want the additional transitive dependencies for the wicket ui in other services than the webui service itself.

The trick to do so is:

• To add exclusions for org.apache.wicket:wicket-core and org.geoserver.web:gs-web-core in the gs-graticule dependency declaration
• To split the autoconfiguration in two @Configuration classes, one for the regular stuff and one for the webui components. In this particular case there's no much to say about the "regular stuff", since the only spring bean in gs-graticule.jar!/applicationContext.xml is the graticuleStorePanel. In any case, there "webui" configuration class should be made conditional in such way that it only engages if the wicket ui is "present" (more on this later).
• Finally, I also just realized the wms-extensions module is not the proper place for this. What the graticules module really does is to add an additional vector datasource, that happens to create the features on the fly, but still, any layer set up with it can also be used through the WFS for example. So, it belongs to the gs-cloud-starter-vector-formats module.

To summarize:

• In src/pom.xml we declare the dependency with the exclusions mentioned above
• In gs-cloud-starter-vector-formats we add the dependency. No @Configuration class is needed here for the GraticuleDataStoreFactory itself because it only adds a DataStoreFactory that's discovered through SPI, not through spring beans.
• Now for the webui configuration, we will have to add an @AutoConfiguration that's, for example, @ConditionalOnClass(org.geoserver.web.GeoServerApplication.class). To do that, in gs-cloud-starter-vector-formats's pom.xml you'll have to add the org.geoserver.web:gs-web-core dependency with <optional>true</optional>. Meaning it's optional and won't be transitively propagated. So, in the webui service, the class will be present and the conditional satisfied, hence the wicket panel contributed to the app context. But in the other services that also depend on
  gs-cloud-starter-vector-formats, the conditional won't match.

Hope that makes sense.

One last thing, I see you've added three commits with messages that don't add new information to the purpose of the pr. In those cases it's better squash them into a single one with a single commit message that makes sense.
Oh and the new test class has the wrong class header:

/*
 * Author : Adnovum Informatik AG
 */

[vuilleumierc]

Hi @groldan, thanks a lot for the detailed break down.
About the commits, I figured you might have checked out the branch and thus didn't want to break the linear history, I'll squash directly next time. I also need to adapt some of my IDE settings for the header.
Thank again for your advice, I should be able to work on that soon

[vuilleumierc]

Working on a new branch