Good discussion, comments inline, and I think we may done our strategy. > > - geotools, removed the "--add-modules", added jaxb and activation to > imagemosaic and solr, one odd test failure that I have ignored for the > moment (it's about checking one init clause), some differences in rendering > that I still need to look into, but PR (just for the sake of having a look, > please don't merge) here: > https://github.com/geotools/geotools/pull/2100 > > I really like those activation dependencies, the other examples I found online were far more complicated. Fixing the java docs also does not look too difficult.
One dev, three projects, less than a hour to get some basic build going > without any flag.... I'll call your "not sure if this is possible" and > raise a "pretty doable". > That is *great*! The sad outcome of the experiment are build times... with java 8 I build > in 4:30 (with a -T8 on a 8 core CPU), > on java 11 it takes 7+ minutes (holy cow!) > That must of been a lot of warnings, or is the new compiler just slower? I don't disagree here, but let's do it in waves, first repackage and > modularize geotools, then gwc, then gs (in this order, having everythig > building and running at the end of each step). > Yes, the more small "shippable" steps the better. No, no, and no... it's not required to run on JDK 11, we'll do it once > everything else is working. We can cut some time off the "running without > warning" as I'm afraid it might just not be feasible, let's strive to > remove as many warnings as possible, but don't get too caught up if they > originate from dependent libraries, that will likely solve itself. > > This should make enough time to do geoapi switch towards the end. > Suggestion, someone should try to figure out which Eclipse version we > should use to rebuild the EMF bindings, in my experience each of the EMF > module needs its own blessed old Eclipse version to build at all (not all > build with the same version). > I have a bunch of the old eclipse versions on hand. > Maybe, maybe not. Repackaging the most core modules that EMF bindings > depend onto will hopefully mostly mean moving classes between jars. > Okay I can see that, we really only care about api change, the implementations inside the generated code were never generated and can be edited to reflect any changes made. I expect that some implementations will change package, and some methods will change from "package visible" to public, but neither of these would effect EMF method signatures. To be clear, I'm not against switching GeoAPI, I'm against doing it along > with the other changes. > Thanks for explaining how that can work. I had hoped that we could do some of these in parallel, example spring 5 update happening and landing on master, while geotools is repackaged. Then merge in geotools repackage, running the "sed scripts" to update the gwc and gs codebase as part of merging the gt change. That needs to be vetted carefully, but yes, I guess we can work on some > depdencies upgrade while repackaging happens. > Any other good ideas on how to work across timezones and teams? And we should start making a list of participants to have ready for "day 1".
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
