On Tue, Feb 6, 2018 at 3:43 PM, Jody Garnett <[email protected]> wrote:
> 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
>
> Yes
> Is the the implementation still available via ServiceLocator ... like can
> it still be found as a "Function", just not using the class name
> CustomFunction?
>
>
I'm not certain.
This seems to be covered in some detail here
<http://openjdk.java.net/projects/jigsaw/spec/sotms/#services>.
>From what can gather, the interface can define a "uses" class, e.g.:
module org.geotools.filter {
requires ...
exports ...
exports org.geotools.filter.function;
uses org.geotools.filter.function.Function;
}
Then, the implementor indicated it "provides" an implementation of that
interface, e.g.:
module org.geotools.unsupported.custom {
requires ...
requires org.geotools.filter;
exports ...
provides org.geotools.filter.function.Function with
org.geotools.filter.function.CustomFunction;
}
I believe this would allow CustomFunction to get picked up by the
ServiceLocator, although only exposed as a Function. So this should work
fine.
Torben
> 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/geoto
>> ols/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
