Re: [OSGeo-Discuss] Java 11 code sprint taking shape for October 22-26th

2018-09-18 Thread Jody Garnett 
Excellent! I will set budget accordingly, goal being to gather if we can.

On Tue, Sep 18, 2018 at 1:02 AM María Arias de Reyna 
wrote:

> Hi,
>
> I have a tentative proposal from the local Java developer group here
> in Sevilla to host and participate with volunteers on the codesprint
> for GeoNetwork (which is where I can help most). Not sure how well
> this will go, as most of them has no GIS experience, but I'm excited!
>
> On Tue, Sep 18, 2018 at 9:58 AM Torsten Friebe  wrote:
> >
> > Hi Jody,
> >
> > thanks for setting up this code sprint. For the deegree project this
> > is very important too. Besides getting deegree ready for Java 11+ we
> > are also facing the issue that deegree code has dependencies to
> > Oracle's JAI and other outdated libraries.
> > I will share this with the deegree Developer mailing list and
> > hopefully we can join the code sprint.
> >
> > Cheers
> > Torsten
> >
> > Zitat von Jody Garnett :
> >
> > > When:  October 22-26th
> > > Where: North America (Victoria, BC), Europe (Italy or UK proposed),
> Oceania
> > > (recommendations welcome)
> > > Wiki: https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint
> > >
> > > If you or your project is interested in taking part, even remotely,
> please
> > > add yourself to the above wiki page!
> > >
> > > The Java community has a challenge ahead, with recent policy changes
> > > setting the Java platform on a six-month release cycle. We also have
> > > a *python3
> > > moment* as our open source libraries are tasked with upgrading to the
> use
> > > of the "jigsaw" module system.
> > >
> > > Top level applications like GeoServer and GeoNetwork need to make some
> > > changes in order to run at all. Mostly this requires a dependency
> review,
> > > upgrading to new libraries such as Spring 5 that are compatible with
> Java
> > > 11. Many of these libraries are broken due to changes to how
> reflection is
> > > handled.
> > >
> > > Java libraries like JTS and GeoTools are put in an awkward position as
> a
> > > bottleneck on the safe use of the module system (see module hell
> problem
> > > ).
> A
> > > further complication for is a restriction preventing two jars from
> making
> > > use of the same package.
> > >
> > > Planning is currently underway:
> > >
> > >- GSIP 171 Java 18.9 Compatibility
> > > (GeoServer)
> > >- Strategy for GeoNetwork
> > >
> > > <
> https://github.com/geonetwork/core-geonetwork/wiki/OSGeo-Java-codesprint-2018
> >
> > >- Restructure GeoTools into Jigsaw modules
> > >
> > > <
> https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules
> >
> > >
> > > Recommended reading:
> > >
> > >- What Comes After JDK 8? <
> https://www.azul.com/what-comes-after-jdk-8/> -
> > >java release cycle changes
> > >- It's time! Migrating to Java 11
> > >
> > > <
> https://medium.com/criciumadev/its-time-migrating-to-java-11-5eb3868354f9>
> > > -
> > >spring upgrade example
> > >- The State of the Module System
> > > - technical
> > >background
> >
> >
> > --
> > ### -->  Bitte beachten Sie unsere neuen Rufnummern!  <--  ###
> >
> > l a t / l o n  GmbH
> > Aennchenstrasse 1953177 Bonn, Germany
> > phone ++49 +228 9477 9877 fax ++49 +228 9477 0154
> > http://www.lat-lon.de http://www.deegree.org
> >
> > lat/lon gesellschaft für raumbezogene informationssysteme mbH
> > Registergericht: Amtsgericht Bonn, HRB 13042
> > Geschäftsführer: Jens Fitzke und Torsten Friebe
> >
> > ___
> > Discuss mailing list
> > Discuss@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/discuss
>
-- 
--
Jody Garnett
___
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Java 11 code sprint taking shape for October 22-26th

2018-09-18 Thread María Arias de Reyna 
Hi,

I have a tentative proposal from the local Java developer group here
in Sevilla to host and participate with volunteers on the codesprint
for GeoNetwork (which is where I can help most). Not sure how well
this will go, as most of them has no GIS experience, but I'm excited!

On Tue, Sep 18, 2018 at 9:58 AM Torsten Friebe  wrote:
>
> Hi Jody,
>
> thanks for setting up this code sprint. For the deegree project this
> is very important too. Besides getting deegree ready for Java 11+ we
> are also facing the issue that deegree code has dependencies to
> Oracle's JAI and other outdated libraries.
> I will share this with the deegree Developer mailing list and
> hopefully we can join the code sprint.
>
> Cheers
> Torsten
>
> Zitat von Jody Garnett :
>
> > When:  October 22-26th
> > Where: North America (Victoria, BC), Europe (Italy or UK proposed), Oceania
> > (recommendations welcome)
> > Wiki: https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint
> >
> > If you or your project is interested in taking part, even remotely, please
> > add yourself to the above wiki page!
> >
> > The Java community has a challenge ahead, with recent policy changes
> > setting the Java platform on a six-month release cycle. We also have
> > a *python3
> > moment* as our open source libraries are tasked with upgrading to the use
> > of the "jigsaw" module system.
> >
> > Top level applications like GeoServer and GeoNetwork need to make some
> > changes in order to run at all. Mostly this requires a dependency review,
> > upgrading to new libraries such as Spring 5 that are compatible with Java
> > 11. Many of these libraries are broken due to changes to how reflection is
> > handled.
> >
> > Java libraries like JTS and GeoTools are put in an awkward position as a
> > bottleneck on the safe use of the module system (see module hell problem
> > ). A
> > further complication for is a restriction preventing two jars from making
> > use of the same package.
> >
> > Planning is currently underway:
> >
> >- GSIP 171 Java 18.9 Compatibility
> > (GeoServer)
> >- Strategy for GeoNetwork
> >
> > 
> >- Restructure GeoTools into Jigsaw modules
> >
> > 
> >
> > Recommended reading:
> >
> >- What Comes After JDK 8?  
> > -
> >java release cycle changes
> >- It's time! Migrating to Java 11
> >
> > 
> > -
> >spring upgrade example
> >- The State of the Module System
> > - technical
> >background
>
>
> --
> ### -->  Bitte beachten Sie unsere neuen Rufnummern!  <--  ###
>
> l a t / l o n  GmbH
> Aennchenstrasse 1953177 Bonn, Germany
> phone ++49 +228 9477 9877 fax ++49 +228 9477 0154
> http://www.lat-lon.de http://www.deegree.org
>
> lat/lon gesellschaft für raumbezogene informationssysteme mbH
> Registergericht: Amtsgericht Bonn, HRB 13042
> Geschäftsführer: Jens Fitzke und Torsten Friebe
>
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Java 11 code sprint taking shape for October 22-26th

2018-09-18 Thread Torsten Friebe 

Hi Jody,

thanks for setting up this code sprint. For the deegree project this  
is very important too. Besides getting deegree ready for Java 11+ we  
are also facing the issue that deegree code has dependencies to  
Oracle's JAI and other outdated libraries.
I will share this with the deegree Developer mailing list and  
hopefully we can join the code sprint.


Cheers
Torsten

Zitat von Jody Garnett :


When:  October 22-26th
Where: North America (Victoria, BC), Europe (Italy or UK proposed), Oceania
(recommendations welcome)
Wiki: https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint

If you or your project is interested in taking part, even remotely, please
add yourself to the above wiki page!

The Java community has a challenge ahead, with recent policy changes
setting the Java platform on a six-month release cycle. We also have  
a *python3

moment* as our open source libraries are tasked with upgrading to the use
of the "jigsaw" module system.

Top level applications like GeoServer and GeoNetwork need to make some
changes in order to run at all. Mostly this requires a dependency review,
upgrading to new libraries such as Spring 5 that are compatible with Java
11. Many of these libraries are broken due to changes to how reflection is
handled.

Java libraries like JTS and GeoTools are put in an awkward position as a
bottleneck on the safe use of the module system (see module hell problem
). A
further complication for is a restriction preventing two jars from making
use of the same package.

Planning is currently underway:

   - GSIP 171 Java 18.9 Compatibility
    (GeoServer)
   - Strategy for GeoNetwork



   - Restructure GeoTools into Jigsaw modules




Recommended reading:

   - What Comes After JDK 8?  -
   java release cycle changes
   - It's time! Migrating to Java 11



-
   spring upgrade example
   - The State of the Module System
    - technical
   background



--
### -->  Bitte beachten Sie unsere neuen Rufnummern!  <--  ###

l a t / l o n  GmbH
Aennchenstrasse 1953177 Bonn, Germany
phone ++49 +228 9477 9877 fax ++49 +228 9477 0154
http://www.lat-lon.de http://www.deegree.org

lat/lon gesellschaft für raumbezogene informationssysteme mbH
Registergericht: Amtsgericht Bonn, HRB 13042
Geschäftsführer: Jens Fitzke und Torsten Friebe

___
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] Java 11 code sprint taking shape for October 22-26th

2018-09-17 Thread Jody Garnett 
When:  October 22-26th
Where: North America (Victoria, BC), Europe (Italy or UK proposed), Oceania
(recommendations welcome)
Wiki: https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint

If you or your project is interested in taking part, even remotely, please
add yourself to the above wiki page!

The Java community has a challenge ahead, with recent policy changes
setting the Java platform on a six-month release cycle. We also have a *python3
moment* as our open source libraries are tasked with upgrading to the use
of the "jigsaw" module system.

Top level applications like GeoServer and GeoNetwork need to make some
changes in order to run at all. Mostly this requires a dependency review,
upgrading to new libraries such as Spring 5 that are compatible with Java
11. Many of these libraries are broken due to changes to how reflection is
handled.

Java libraries like JTS and GeoTools are put in an awkward position as a
bottleneck on the safe use of the module system (see module hell problem
). A
further complication for is a restriction preventing two jars from making
use of the same package.

Planning is currently underway:

   - GSIP 171 Java 18.9 Compatibility
    (GeoServer)
   - Strategy for GeoNetwork
   

   - Restructure GeoTools into Jigsaw modules
   


Recommended reading:

   - What Comes After JDK 8?  -
   java release cycle changes
   - It's time! Migrating to Java 11
   
-
   spring upgrade example
   - The State of the Module System
    - technical
   background
___
Discuss mailing list
Discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss