Consider a deployment with just OGC APIs

[aaime]

This is interesting but also complex given the current dependencies. From @aaime mail

To go where you want, and limiting attention to Features, we need to:

• Build a new module, gs-features-core, that only have DefaultWebFeatureService and its basic support classes
• Untangle it from the WFS specific EMF objects
• Untangle the output formats so that each gets its separate set of dependencies (since GML are heavily married to EMF and schemas, but GeoJSON is not)
• Make wfs and ogc-api-features depend on what they need, and no more
  And then basically rinse and repeat for the other services (for extra fun, consider that today you cannot have WMS without WFS around, due to GetFeatureInfo depending on GML outputs).

I'll note this general kind of refactor is beneficial in any case to projects like GeoServer cloud (reduce the size of micro-services and the amount of EMF/XSD they need to keep in memory)

[jodygarnett]

Q: Approach?

Right now mvn install -Pogcapi makes a geoserver.war that includes OGCAPI-Features.

Jody suggests a war overlay if we want a download that includes in an OGCAPI-Features by default, if we want to get rid if other stuff.

Q: Can I have have separate data directory only?

• Not quite yet as WFS needs to be enabled right now.
• Long term WFSServiceInfo could be enabled, and conformances for WFS1.0, WFS 1.1, WFS2.0 to disable the specific things.

Or make make

Andrea indicates that the Docker instructions are "fine/funcitonal" for now, the example is in the GeoServer website.

Q: Can we have a smaller / lighter geoserver download?

No - because XSD/EMF is the heavy part and we need it to parse requests / responses right now.