On Tue, Sep 25, 2018 at 9:13 PM Jody Garnett <jody.garn...@gmail.com> 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 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

Reply via email to