> "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 > Good article, if discouraging result.
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
