Sent a proposal out with the high level plan for this week - it has not been approved: https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules Andrea had a question to see if we could break gt-main into smaller modules (which is addressed bellow).
Now that we are into the details it is breaking out into several steps: 1) Distribute gt-api classes around the library *This action is taking place today as part of the code sprint (it is required to avoid split packages).* 2) Go through and repackage the library (priority is avoiding split packages) See tab "Stage 3 - Split Modules", any package in bold represents a change Java 2018 Code Sprint Activities <https://docs.google.com/spreadsheets/d/1oE6mU4jp-ZL5PebgXf-fuhtf7MY5dzSwPqpMtrzdZ94/edit?usp=drive_web> Mostly straight forward, with only a couple hard choices: - The org.geotools.factory package is used for two popular classes. gt-main wins the package due to CommonFactoryFinder, gt-util will move Hints to org.geotools.util.factory And a few made for ascetic consistency: - org.geotools.renderer.windbarbs --> org.geotools.renderer.*style* .windbarbs - org.geotools.renderer.markwkt --> org.geotools.renderer.*style*.markwkt *This action is taking place today as part of the code sprint (it is required to avoid split packages).* 3) Breaking up gt-metadata into two modules gt-util and gt-metadata gt-metadata becomes: - gt-util - focused on java helper classes and integration work like Factory and LazySet - gt-metadata - implementing org.opengis.metadata interfaces *This action is scheduled for tomorrow time permitting.* 4) *Feedback/Awareness needed*: Breaking the library into smaller modules Planned for this based on Andrea's question about gt-main - it is possible here is how it worked out: gt-util split into: - gt-util - java creature comforts like LazySet and null safe equals - gt-logging - the logging redirection code - gt-factory - the service locator / service registry code representing the geotools "plugin" system gt-referencing split into: - gt-geometry-iso - may be possible to split these out (although geometry CoordinateReferenceSystem may tie them together) - gt-referencing - coordinate reference system care and feeding gt-main split into: - gt-main: common factory finder, depends on others (due to transitive dependencies downstream code unaffected by split) - gt-filter - gt-feature - gt-geometry-jts - gt-ows - open web service data model used by gt-wms, gt-wmts, etc... - gt-xml - some code moves to gt-xml - gt-util - some code moves to gt-util gt-coverage: - gt-image - all the org.geotools.image packages - gt-coverage - all the org.geotools.coverage packages gt-cql: - gt-filter - one function moves to gt-filter *Please consider and vote on the proposal* 5) *Feedback/Awareness needed*: Breaking up gt-opengis into geotools packages Planning is done, and is important to determine if the above "smaller modules" will work. *Holding off on this due to impact on downstream code, and the pain of updating EMF models.* *Going to keep this for a future proposal.* -- Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
