1. remove org.opengis packages > >> It seems like good timing, and with the module system any conflict over >> org.opengis packages will be more keenly felt. >> >> Here is the proposal renaming org.opengis to org.geotools.api: >> - org.geotools.api.filter.Filter >> - org.geotools.api.filter.PropertyIsEqualTo >> - org.geotools.filter.FilterAbstract >> - org.geotools.filter.IsEqualsToImpl >> > > I like the direction, but does not seem a requirement, more of a nice to > have. Can we do it towards the end, when everything > is building and ready to merge in mainline? >
We may be able to move it near the end - but I think it is a requirement for the work. As such I would rather tackle this head on, so we can manage the interfaces coming from gt-opengis and gt-api sensibly. > 2. folding gt-cql together gt-main >> >> ECQL is now a well established stable part of our library, moving it >> closer should allow us to use it in more places helping with ease of use. >> > > Hmm... tentatively -1. OGC is working on lighter protocols and with those > will likely come (finally) some easier > to use filtering languages. I've tried to promote CQL with no success so > far. I'd wait and see what comes up instead > of making CQL "built-in". > That is a good reason to be -1, we may be able to make it an extension (something that makes the core geotools library easier to use). > Also the direction of Java 9 modularity seems, from what I've read so far, > to have relatively small and focused modules, > with eventual aggregator modules (e.g. java.base) that contain nothing but > dependencies. If we headed that direction we'd rather have to split main > into smaller bits. Not saying we must or should, just noting a difference > in approach. > I am willing to try this as an experiment. I note that the individuals modules in the JRE have *lots* of packages in them (even though they have an aggregator module as an easy way to depend on "everything"). Indeed all the illustrations have "..." in them to avoid listing all the packages. 3. Priority to change packages, but strictly not change interface / class >> names >> >> If we relaxed the "no changing classnames" guidelines we could gather >> these into a single package: >> - org.geotools.style.PolygonSymbolizer - readonly >> - org.geotools.style.PolygonSymbolizer2 - mutable >> - org.geotools.style.PolygonSymbolizerImpl >> > > What about a grep/sed/ant/whatever script based approach instead? We could > test the script on an un-upgraded version of GeoServer. > I agree, was hoping to use eclipse "api baseline" automatically collect refactoring that could be applied to GeoServer and other codebases. Sed script is easier for everyone so may be worth creating manually. What do you think about "PolygonSymbolizer" and "PolygonSymbolizer2" though?
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
