Point of clarification; on the following:
*The major issue we are currently facing is the new constraint that any two
modules must not export the same package. In other words, no two modules
may make the same package accessible to any other module (so two modules
containing the same package is OK, as long as only one of those modules
makes that package visible).*
For the case where a jar makes its own CustomFunction, using the shared "
org.geotools.filter.function
<http://docs.geotools.org/stable/javadocs/org/geotools/filter/function/package-summary.html>"
shared package - the implementation is fine to compile - it just cannot be
published right
Is the the implementation still available via ServiceLocator ... like can
it still be found as a "Function", just not using the class name
CustomFunction?
The OSGi module system works this way ... it may not be a bad thing if we
tighten up our library to encourage use via FunctionFactory, rather than
encourage the few examples where classes are used directly.
--
Jody Garnett
On 6 February 2018 at 15:04, Torben Barsballe <[email protected]>
wrote:
> Continuing from discussions in todays PMC meeting:
>
> We currently have a proposal tracking Java 9 compatibility here:
> https://github.com/geotools/geotools/wiki/Java-9-Compatibility
> I have updated it with more details.
> The is also a PR containing a number of preliminary changes required for
> Java 9 Compatibility awaiting review here: https://github.com/
> geotools/geotools/pull/1798
>
> At this point, the next steps for Java 9 (and future) compatibility are
> *blocked
> awaiting PMC discussion and consensus*:
>
> In order to support the module system, some amount of API changes are
> required (For a helpful primer on the module system, read The State of
> the Module System <http://openjdk.java.net/projects/jigsaw/spec/sotms>)
> The major issue we are currently facing is the new constraint that *any
> two modules must not export the same package*. In other words, no two
> modules may make the same package accessible to any other module (so two
> modules containing the same package is OK, as long as only one of those
> modules makes that package visible).
>
> This is primarily an issue in the core library classes, particularly
> between gt-api/gt-main/gt-referencing, and between gt-data/gt-jdbc. There
> are also some issues with gt-process and plugins which implement their own
> processes.
>
> A few options have been identified for handling this issue:
>
> 1. Retain current names, and change package structure
> Under this approach, all geotools modules would remain standalone modules
> under the Java Module System.
> However, packages within each module would be renamed so as not to violate
> the duplicate package restriction.
> This would cause massive API changes across core GeoTools, and is not
> recommended.
>
> 2. Combine modules which share packages.
> Under this approach, geotools modules with significant shared packages
> would be combined into a single Java module.
> This would require structural changes to certain parts of the GeoTools
> repo, and dependency changes for downstream projects, but would result in
> minimal API changes.
>
>
> Given that this will be a substantial change to several core parts of
> GeoTools regardless of what approach is taken, some measure of consensus
> from the PMC is required before moving forward.
> Also, if anyone can think of a third approach, suggestions are welcome.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
