That is good to know.
I expect the correct path forward is to *focus on not breaking the the core
api *resulting in something in-between your two ideas:
For the core library we would need to "*combine modules which share
packages*"
- gt-util - helpers, factories, etc...
- gt-referencing - combing refereeing, metadata, etc...
- gt-main - combine main, api and extras like cql
- gt-data - combine data, jdbc, and a whole lot of api and main
- gt-coverage - combine coverage with a fair bit of api
- gt-render
- gt-xml
- gt-test - can take over from gt-sample-data
For plugins and extensions, I hope the majority of them will not end up
with package conflicts....
For the plugins and the second "*retain current names, and change package
structure*" approach - we may be able to use the "provides" to preserve
compatibility without further code changes even in the event of package
conflict.
For extensions I think they are in good shape, each providing its own
packages.
--
Jody Garnett
On 6 February 2018 at 16:01, Torben Barsballe <[email protected]>
wrote:
>
>
> 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
