Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Jody Garnett 
> By the way, how does Jigsaw work with optional dependencies? Can we
> still leave out unused dependencies like with the current classpath? Or
> will Java 11 spit the dummy?
>

Good question, here is my speculation:

If the dependency is something like log4j and we have adapting code that we
can use if it is available - we should be able to use reflection on the
module-info.java to check if something is around providing that package.
Cannot see any real benefit over our current technique of doing
Class.forName call and catching an exception :P

Modules still follow SPI - so can make functionality available via
ServiceLocator. That should work for both modules and classpath
implementations.

For the oracle case - our oracle dummy jar should be fine to compile a
module against. I am just going to ask the DataStore factory have
isAvailable to check for the JDBCDriver and isAvailableStatus to explain to
the user what went wrong if necessary.

If we were purely going to Java 11 we could have the gt-jdbc-oracle module
require the jdbc driver and refuse to load if it was not available.

We will need to understand the impact on downstream, especially
> GeoServer. Especially gs-app-schema-test. Especially especially tests
> that depend on GeoTools tests. I am still trying to understand the
> implications


Is there anything we can sort out prior to the code sprint here? For
geotools tests we should probably test on the classpath, if we eventually
modularize the tests we would need to explicitly grant access.

looks like surefire uses a hack, --patch-module to allow tests to be slide
loaded along side the module they are testing.[1]

Red Hat are supporting OpenJDK 8 until 2023. OpenJDK 8 forever!
>

Pragmatic, as I expected this is our Python 2 vs 3 moment.

[1]
https://stackoverflow.com/questions/46613214/java-9-maven-junit-does-test-code-need-module-info-java-of-its-own-and-wher
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Ben Caradoc-Davies 

On 27/09/2018 10:01, Jody Garnett wrote:

Hey Ben - are you available for the code sprint? Completely understand if
you are not being a small business, but we would really love your help.


Sorry, I am not likely to be available.


Additional comments/confusion inline:
On Wed, 26 Sep 2018 at 14:50, Ben Caradoc-Davies  wrote:

Does Jigsaw prevent classpath trickery like gt-xsd-gml3
org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required
to make tests pass in Eclipse.

What CLASSPATH trickery is that? Reading the java docs:
* * A disabled version of {@link EPSGCRSAuthorityFactory} that exists
solely as a workaround for*
* * Eclipse capture of transitive dependencies. The real implementation in
gt-epsg-wkt; Maven does*
* * the right thing and does not include the provider at test time, but
Eclipse captures it as a*
* * transitive dependency, causing the wrong provider to be used for
srsName encoding. The presence*
* * of this class allows gt-xsd-gml3 unit tests to pass in Eclipse.*
Since you are the author you may need to explain the trick?


Eclipse puts project classes before dependency classes on the classpath. 
This class allows us to replace an unwanted class in a transitive 
dependency (Eclipse includes more dependencies than Maven) that 
otherwise causes tests to fail (axis order, IIRC?). Jigsaw exists to 
prevent this.


By the way, how does Jigsaw work with optional dependencies? Can we 
still leave out unused dependencies like with the current classpath? Or 
will Java 11 spit the dummy?



Are modules like gt-app-schema that define classes in several packages
also defined in other modules affected by this change?

Yes, they will need to be untangled.
I guess that it might be because only one module can publish a package, but

this depends
on whether any other module consumes these classes.

Normally it would - ie if we were going all in on Java 11 and using
module-info.java to carefully control what we are publishing.
We are not .. as an "automatic module" all the public packages are
published.


We will need to understand the impact on downstream, especially 
GeoServer. Especially gs-app-schema-test. Especially especially tests 
that depend on GeoTools tests. I am still trying to understand the 
implications.



Thanks for the excellent proposal, by the way. This is the most

comprehensible explanation of Jigsaw that I have seen.

No worries, there are a couple features that make it not as scary as I
first feared. And indeed some (like "automatic modules" acting as a bridge
to the classpath) that can be used to make our transition gradual and not
stuck on waiting for everything ever to be turned into modules.


I added Nuno and Torben to the proposal.

Red Hat are supporting OpenJDK 8 until 2023. OpenJDK 8 forever!

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Jody Garnett 
Hey Ben - are you available for the code sprint? Completely understand if
you are not being a small business, but we would really love your help.

Additional comments/confusion inline:
On Wed, 26 Sep 2018 at 14:50, Ben Caradoc-Davies  wrote:

> Does Jigsaw prevent classpath trickery like gt-xsd-gml3
> org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required
> to make tests pass in Eclipse.
>
>
What CLASSPATH trickery is that? Reading the java docs:

* * A disabled version of {@link EPSGCRSAuthorityFactory} that exists
solely as a workaround for*
* * Eclipse capture of transitive dependencies. The real implementation in
gt-epsg-wkt; Maven does*
* * the right thing and does not include the provider at test time, but
Eclipse captures it as a*
* * transitive dependency, causing the wrong provider to be used for
srsName encoding. The presence*
* * of this class allows gt-xsd-gml3 unit tests to pass in Eclipse.*

Since you are the author you may need to explain the trick?


> Are modules like gt-app-schema that define classes in several packages
> also defined in other modules affected by this change?


Yes, they will need to be untangled.

I guess that it might be because only one module can publish a package, but
> this depends
> on whether any other module consumes these classes.
>

Normally it would - ie if we were going all in on Java 11 and using
module-info.java to carefully control what we are publishing.
We are not .. as an "automatic module" all the public packages are
published.

Thanks for the excellent proposal, by the way. This is the most
> comprehensible explanation of Jigsaw that I have seen.
>

No worries, there are a couple features that make it not as scary as I
first feared. And indeed some (like "automatic modules" acting as a bridge
to the classpath) that can be used to make our transition gradual and not
stuck on waiting for everything ever to be turned into modules.
--
Jody
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Ben Caradoc-Davies 
Does Jigsaw prevent classpath trickery like gt-xsd-gml3 
org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required 
to make tests pass in Eclipse.


Are modules like gt-app-schema that define classes in several packages 
also defined in other modules affected by this change? I guess that it 
might be because only one module can publish a package, but this depends 
on whether any other module consumes these classes.


Thanks for the excellent proposal, by the way. This is the most 
comprehensible explanation of Jigsaw that I have seen.


Kind regards,
Ben.

On 18/09/2018 11:16, Jody Garnett wrote:

Proposal is here: Restructure GeoTools into Jigsaw modules


Feedback welcome, I expect we will have some discussion before voting.
--
Jody Garnett



___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel



--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Andrea Aime 
On Wed, Sep 26, 2018 at 8:12 PM Jody Garnett  wrote:

>
> "I think it is a requirement for the work". The work is "Restructure
>> GeoTools into Jigsaw modules" and covers two items:
>> * Providing an automatic module name for each jar
>> * Refactoring the codebase to avoid package conflicts
>>
>> Can you explain how this package renaming is required for the job, or how
>> the goal would be unattainable without, or would require more
>> time to attain if we did not do this package rename?
>>
>
> Renaming the "org.opengis" packages, or moving their classes elsewhere, is
> not required to do the work.
>

Thanks for confirming


> - I think it is smart as we are in conflict over the use of these package
> names (not sure about you but I get emails from the ogc about this)
> - No party interested in OGC GeoAPI compatibility has come forward
>
> This is a good opportunity to fix as the library is already being
> refactored.
>

It is indeed, and we can do it at the end once everything else is working,
ending up with an unfinished port because we wasted
time on a good but unrelated opportunity would simply be irresponsible.


> The upgrade work will have to go over all supported modules, all
>> unsupported of common usage (e..g, wfs, css, csv), and make sure they still
>> work.
>> That's a ton of stuff, we are talking hundreds of modules spread across
>> various projects that we'll have to vet both at compile time and at runtime.
>> I'm worried that we might not have the manpower to do so, and yet,
>> failing to do so will give us a crippled GeoServer that would need further
>> (unfunded) work in the months to come.
>>
>
> I agree we need a lot more people for the code sprint. I made a blog post
> on the geoserver blog seeking contributors (and sponsors so we can attract
> more contributors who would otherwise be paying out of pocket to attend).
>

What we have now in the table is likely who we can expect to participate
full time. We might get more, but not for sure, and probably not full time.
Hence me pushing for keeping the sprint focused.

Cheers
Andrea

-- 

Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Jody Garnett 
> "I think it is a requirement for the work". The work is "Restructure
> GeoTools into Jigsaw modules" and covers two items:
> * Providing an automatic module name for each jar
> * Refactoring the codebase to avoid package conflicts
>
> Can you explain how this package renaming is required for the job, or how
> the goal would be unattainable without, or would require more
> time to attain if we did not do this package rename?
>

Renaming the "org.opengis" packages, or moving their classes elsewhere, is
not required to do the work.
- I think it is smart as we are in conflict over the use of these package
names (not sure about you but I get emails from the ogc about this)
- No party interested in OGC GeoAPI compatibility has come forward

This is a good opportunity to fix as the library is already being
refactored.

The more I look into it, the more I'm worried, globally. Looking around, we
> are the community that has some migration steps laid out,
> I did not see others with the same level of detail. I'm thus guessing
> we'll have to spend some time assisting other communities in their
> migration as well.
>

I was worried as well, and then I noticed:
- We can leave many dependencies on the CLASSPATH (no package conflicts on
the classpath)
- GeoTools can act as a bridge to libraries on the CLASSPATH (so modules
using GeoTools do not have to care)
- GeoServer can run on the CLASSPATH (see separate email on geoserver-devel)

Making jai-ext,imageio-ext,jaitools[1],geotools,geowebcache and geoserver
> build on java 11 will require quite the effort, two projects need
> to migrate to a newer version of Spring, we have to setup a new log4j
> dependency (and associated migration guides), and I don't see yet
> a list of other dependencies that might need updates.
>

I think the dependency review is what I will work on for friday then.


> All libraries using reflection might be in trouble[2], one that comes to
> mind is XStream for example:
> https://github.com/x-stream/xstream/issues/101
> I believe there might be others too, like for example the CSS module
> depends on asm, which in turn uses Unsafe, and the parsing library
> has not been updated in a long time (the project is simply done, but with
> these changes, it may become broken and might require
> either a fork of the library or a rewrite of the parser with a different
> technology (e.g., antlr).
> There same might be true for Hibernate[3] (which is used by GeoFence).
>

Short term remaining on the CLASSPATH should allow these to run. Libraries
like xstream can be granted reflection access to our code allowing them to
continue to operate long term. Spring 5 has an ASM fork which we can look
at.

The upgrade work will have to go over all supported modules, all
> unsupported of common usage (e..g, wfs, css, csv), and make sure they still
> work.
> That's a ton of stuff, we are talking hundreds of modules spread across
> various projects that we'll have to vet both at compile time and at runtime.
> I'm worried that we might not have the manpower to do so, and yet, failing
> to do so will give us a crippled GeoServer that would need further
> (unfunded) work in the months to come.
>

I agree we need a lot more people for the code sprint. I made a blog post
on the geoserver blog seeking contributors (and sponsors so we can attract
more contributors who would otherwise be paying out of pocket to attend).


> 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.
>>
>
> We'll have multiple people using different IDEs working on that, so I
> don't see how a eclipse based solution would pan out... wouldn't
> it require to have one developer using eclipse perform all the package
> renames, with all projects loaded (so that renames spread across),
> in advance of the sprint?
>

No it saves up the renames (kind of like a sed script but smarter) and then
they can be replayed on different projects. Admittedly this solution is
Eclipse IDE based but it may be better then writing our own SED scripts.

[1]: we still depend on jaitools, wondering if we'll be forced to finish
> the migration to jai-ext, or if we'll just manage
>   to have it work as is and focus on the actual hard issues
>

It should be fine on the classpath.


> [2]: one workaround would be to open all packages to reflection by force
> of command line options, but this would
>   be both cumbersome for those installing GeoServer from WAR, and not
> future proof
>

I hope for this release to run on the classpath, and as we move some jars
to the module path we can be sure each one opens up additional XStream
reflection access if needed (I hope most things we serialize are public and
not a problem for xstream).


> [3]: This talks a bit about challenges with Hibernate,
>   https://dzone.com/articles/a-practical-guide-to-java-9-migration
>

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-26 Thread Andrea Aime 
On Tue, Sep 25, 2018 at 9:13 PM Jody Garnett  wrote:

> 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.
>

"I think it is a requirement for the work". The work is "Restructure
GeoTools into Jigsaw modules" and covers two items:
* Providing an automatic module name for each jar
* Refactoring the codebase to avoid package conflicts

Can you explain how this package renaming is required for the job, or how
the goal would be unattainable without, or would require more
time to attain if we did not do this package rename?

The more I look into it, the more I'm worried, globally. Looking around, we
are the community that has some migration steps laid out,
I did not see others with the same level of detail. I'm thus guessing we'll
have to spend some time assisting other communities in their migration as
well.
Making jai-ext,imageio-ext,jaitools[1],geotools,geowebcache and geoserver
build on java 11 will require quite the effort, two projects need
to migrate to a newer version of Spring, we have to setup a new log4j
dependency (and associated migration guides), and I don't see yet
a list of other dependencies that might need updates.
All libraries using reflection might be in trouble[2], one that comes to
mind is XStream for example: https://github.com/x-stream/xstream/issues/101
I believe there might be others too, like for example the CSS module
depends on asm, which in turn uses Unsafe, and the parsing library
has not been updated in a long time (the project is simply done, but with
these changes, it may become broken and might require
either a fork of the library or a rewrite of the parser with a different
technology (e.g., antlr).
There same might be true for Hibernate[3] (which is used by GeoFence).

And this is just off the top of my head... has anyone run jdeps on the full
set of jars used in a GeoServer vanilla install (still a small subset
or our universe of jars, but a significant one)  to get a feel of where we
stand? If not I plan to do so myself as spare time allows (might take some
time, need to finish read the book first to understand the implications of
the report better).

The upgrade work will have to go over all supported modules, all
unsupported of common usage (e..g, wfs, css, csv), and make sure they still
work.
That's a ton of stuff, we are talking hundreds of modules spread across
various projects that we'll have to vet both at compile time and at runtime.
I'm worried that we might not have the manpower to do so, and yet, failing
to do so will give us a crippled GeoServer that would need further
(unfunded) work in the months to come.

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.
>

We'll have multiple people using different IDEs working on that, so I don't
see how a eclipse based solution would pan out... wouldn't
it require to have one developer using eclipse perform all the package
renames, with all projects loaded (so that renames spread across),
in advance of the sprint?


What do you think about "PolygonSymbolizer" and "PolygonSymbolizer2" though?
>

I haven't reached there yet, still trying to collect my thoughts on the
global sprint effort, looking at the whole
playing field before getting into specific issues.

Cheers
Andrea

[1]: we still depend on jaitools, wondering if we'll be forced to finish
the migration to jai-ext, or if we'll just manage
  to have it work as is and focus on the actual hard issues
[2]: one workaround would be to open all packages to reflection by force of
command line options, but this would
  be both cumbersome for those installing GeoServer from WAR, and not
future proof
[3]: This talks a bit about challenges with Hibernate,
  https://dzone.com/articles/a-practical-guide-to-java-9-migration

== GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
(LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-25 Thread Jody Garnett 
Okay Java 11 is here:

- http://jdk.java.net/11
-
https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html

I would like to start on branch for this restricting on Friday, or
experiment to resolving any feedback/questions from this discussion thread.
Candidates for experimentation:
- breaking the library into much smaller modules (to see if we like that
approach)
- Eclipse "api-baseline" based refactor of geotools, then replay the same
steps on GeoServer
- Refactor of geotools, along side sed script for updating GeoServer
--
Jody Garnett


On Mon, 17 Sep 2018 at 16:16, Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-25 Thread Jody Garnett 
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

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-22 Thread Jody Garnett 
Thanks for the discussion - you have given me some items to think about.

For the plugins I only found a few conflicts, gt-epsg-hsql for example,
where an implementation uses the same package name on purpose (I think to
access some package visible API).

Technically there is one other approach to the split-package issue - but it
is only available if using module-info.java.  An implementation (in an
otherwise conflicting package) can be made available via ServiceLocator.
There is a section in module-info.java that replaces META_INF/services. The
class cannot be seen, but the implementation is available as an instance of
the requested service.

On Sat, Sep 22, 2018 at 2:42 AM Andrea Aime 
wrote:

> 4. Priority to core library, plugins are expected to repackage
>>
>> I am pretty content with this direction, the majority of plugins have
>> their own distinct package. I am not sure if more sensitivity is required
>> here?
>>
>
> Unsure. The direction you're proposing here looks sensible, but I haven't
> read enough to know
> if there are other approaches to handle the "split package" issue.
>
> Cheers
> Andrea
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa
> 
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
-- 
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-22 Thread Andrea Aime 
On Fri, Sep 21, 2018 at 8:10 PM Jody Garnett  wrote:

> That is great - which book?
>

This one, in its current "early access" version:
https://www.manning.com/books/the-java-module-system
So far good book, the prose flows and has good information.


> 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?


> 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".
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.


>
> 3. Priority to change packages, but strictly not change interface / class
> names
>
> Goal is to allow clients to confidently fix their imports using "organize
> imports" or similar.
>
> While keeping this goal we *could* fold most interfaces back into place:
> - org.geotools.filter.Filter
> - org.geotools.filter.PropertyIsEqualTo
> - org.geotools.filter.FilterAbstract
> - org.geotools.filter.IsEqualsToImpl
>
> However the style interfaces narrowly avoid conflict:
> - org.geotools.style.PolygonSymbolizer - readonly
> - org.geotools.styling.PolygonSymbolizer - mutable
> - org.geotools.styling.PolygonSymbolizerImpl
>
> 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.


> 4. Priority to core library, plugins are expected to repackage
>
> I am pretty content with this direction, the majority of plugins have
> their own distinct package. I am not sure if more sensitivity is required
> here?
>

Unsure. The direction you're proposing here looks sensible, but I haven't
read enough to know
if there are other approaches to handle the "split package" issue.

Cheers
Andrea

-- 

Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-21 Thread Jody Garnett 
That is great - which book?

I trust your intelligence on a wide range of matters, while you research
the technical side - there are a couple strategic decisions in the middle
of this proposal that I would appreciate your guidance / input on.

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

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.

3. Priority to change packages, but strictly not change interface / class
names

Goal is to allow clients to confidently fix their imports using "organize
imports" or similar.

While keeping this goal we *could* fold most interfaces back into place:
- org.geotools.filter.Filter
- org.geotools.filter.PropertyIsEqualTo
- org.geotools.filter.FilterAbstract
- org.geotools.filter.IsEqualsToImpl

However the style interfaces narrowly avoid conflict:
- org.geotools.style.PolygonSymbolizer - readonly
- org.geotools.styling.PolygonSymbolizer - mutable
- org.geotools.styling.PolygonSymbolizerImpl

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

4. Priority to core library, plugins are expected to repackage

I am pretty content with this direction, the majority of plugins have their
own distinct package. I am not sure if more sensitivity is required here?





--
Jody Garnett


On Wed, 19 Sep 2018 at 09:49, Andrea Aime 
wrote:

> Hi Jody,
> I got myself a book on java modularity and reading through it in my spare
> time.
> Will take a couple of weeks I believe before I can add any intelligent
> comment on the proposal, sorry :-)
>
> Cheers
> Andrea
>
> On Tue, Sep 18, 2018 at 1:18 AM Jody Garnett 
> wrote:
>
>> Proposal is here: Restructure GeoTools into Jigsaw modules
>> 
>>
>> Feedback welcome, I expect we will have some discussion before voting.
>> --
>> Jody Garnett
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-19 Thread Andrea Aime 
Hi Jody,
I got myself a book on java modularity and reading through it in my spare
time.
Will take a couple of weeks I believe before I can add any intelligent
comment on the proposal, sorry :-)

Cheers
Andrea

On Tue, Sep 18, 2018 at 1:18 AM Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 

Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
--- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-19 Thread Torben Barsballe 
I've looked over the proposal, and we reviewed it during yesterday's PMC
meeting.

First off, thanks for putting this together.

During discussion, you mentioned we could have Eclipse generate a
refactoring script to use when refactoring other projects to conform to the
GeoTools API changes - while this is an implementation detail, it would be
worthwhile including it in the proposal (And, longer term, including it in
the docs / migration guide).

The outlined approach looks solid, and seems consistent with what I
discovered when working on the initial Java 9 compatibility efforts.
This is going to be a lot of work, and includes substantial API changes,
but everything here seems necessary to support current versions of Java.

+1

Torben




On Mon, Sep 17, 2018 at 4:17 PM Jody Garnett  wrote:

> Proposal is here: Restructure GeoTools into Jigsaw modules
> 
>
> Feedback welcome, I expect we will have some discussion before voting.
> --
> Jody Garnett
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

2018-09-17 Thread Jody Garnett 
Proposal is here: Restructure GeoTools into Jigsaw modules


Feedback welcome, I expect we will have some discussion before voting.
--
Jody Garnett
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel