> > > In terms of objective for the sprint I'd like to see (in this order): > > Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, >> geowebcache, geoserver) builds and run without any flag added, off the >> classpath (it's ok to have warnings). This will allow us to get JDK 11 >> builds going. >> > I am not sure if this is possible, I think the flags are required to run > in Java 11 ... unless: There a very interesting middle ground maven example > where Java 11 is used to compile module-info.java and Java 8 is used to > compile everything else. This would allow us to include a module-info.java > activating the modules without flags. We could even limit this to a > geotools "base jar" that contains this module-info.java acting the required > sections of the JRE. >
Note that Java 11 supports much fewer flags than Java 9 did. While I'm not certain its possible, getting GeoServer to run on JDK 11 with no flags does seem like something we should be aiming for. > > >> Ideally, it would be nice if we could stop and merge on master as soon as >> each of the step is complete, this would ensure we get something really >> done, shows progress, and it hits the build server and the CITE tests (we >> can update the builds as we go to build both on jdk8 and 11). >> > > 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. > I agree stuff like the Spring update could be completed in parallel with some of the other geotools tasks. As a reminder, we do have the geotools-java9 <https://build.geoserver.org/view/geotools/job/geotools-java9/> , geowebcache-java9 <https://build.geoserver.org/view/geowebcache/job/geowebcache-java9/>, and geoserver-java9 <https://build.geoserver.org/view/geoserver/job/geoserver-java9/> jenkins jobs that were set up for testing Java 9. These could pretty easily be updated to use Java 11, and run against our dev branch for the duration of the sprint. Periodic merges to master still sound useful, but those jobs would be a good indicator of how far along things are. Torben > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
