Re: [Geotools-devel] code sprint update w/ JSR 363 transition

César thanks again for the hard work, this has now been merged and both geotools master and geoserver master report success. The upgrading page has instructions for application making the jump top GeoTools 20.x, if you see anything y

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

I looked with Kevin yesterday, nondirect use of units. GWC maintains its own ratio constants for converting between distances. On Fri, Apr 6, 2018 at 2:56 AM César Martínez Izquierdo wrote: > Regarding GWC: I've not tried to recompile GWC, since I'm not familiar > with its code-base, so I don't

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Regarding GWC: I've not tried to recompile GWC, since I'm not familiar with its code-base, so I don't know if changes will be required. I just adapted Geoserver, which is able to compile and pass tests. César On 5 April 2018 at 19:44, Jody Garnett wrote: > Were any changes needed to the GWC proj

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi again, For the moment I have created a new branch (test_units_jsr363_resync) based on the one we have been working. This new branch has been merged with master, so it can be used to test Geoserver. Regarding rebasing: I think it is OK to rebase when the PR is ready to be merged, since we'll no

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

On Thu, Apr 5, 2018 at 7:44 PM, Jody Garnett wrote: > Were any changes needed to the GWC project (which GeoServer depends on). > > I do not mind if we flatten history, generally I prefer to rebase against > master. > Yep, so do I when I work alone... but rebasing against master on a shared branc

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Were any changes needed to the GWC project (which GeoServer depends on). I do not mind if we flatten history, generally I prefer to rebase against master. Before we do, I had a couple usability ideas to bounce off you to make these easier for upgraders. Make use of our Units utility class to mak

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi Cesar, our rule of thumb is "one commit per pull request", mostly to allow easy backporting, but also because some (me for example) don't care to see how you got to the final result, and find distracting going over the many commits. Given this will not be backported and multiple people have wor

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi Andrea, You are right, the branch was created around March 21th, so changes done after that date are missing. I've now tested that Geoserver fully compiles when compiled against a test_units_jsr363 branch which includes latest Geotools master changes. Should I merge Geotools master in the test_

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi Cesar, probably your GeoTools branch is out of date, there is a new copyNamespaceSupport method that has been added March 21th Cheers Andrea On Thu, Apr 5, 2018 at 6:17 PM, César Martínez Izquierdo < [email protected]> wrote: > Hi again, > > Geoserver is properly compiling and passing tests

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi again, Geoserver is properly compiling and passing tests now in the branch, using: mvn -fn clean install There is only one compilation error in the wfs module which seems to be unrelated with the JSR migration (PropertyNameTypeBinding is expecting a method in GML3EncodingUtils which does not e

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi, I've created a branch for working on Geoserver adaptation: https://github.com/dispiste/geoserver/tree/jsr363_units I've also created a PR to allow collaboration: https://github.com/geoserver/geoserver/pull/2828 Best regards, César On 5 April 2018 at 10:17, Jody Garnett wrote: > I understan

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

I understand, the high number of files is due a series of search and replaces (as outlined in the proposal). If it helps I have a few key "huh" areas where I would like your experienced viewpoint (since your name is on the EPSG and ESRI unit formatters). I will go back and start a conversation on t

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

Hi Jody, whoa this is massive, 229 files changed? I won't be able to look at it soon, next week I'm in the US and travelling there during the weekend, next weekend I'll probably be wiped and get some rest. Cheers Andrea On Thu, Apr 5, 2018 at 8:40 AM, Jody Garnett wrote: > And now some days la

Re: [Geotools-devel] code sprint update w/ JSR 363 transition

And now some days later, the pull request passes tests and is ready for review: - https://github.com/geotools/geotools/pull/1834 I have continued to update the proposal with notes about any api changes (especially bulk search an

[Geotools-devel] code sprint update w/ JSR 363 transition

The proposal page ( https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363) has been updated over the course of the sprint. The PR (https://github.com/geotools/geotools/pull/1834) is not quite ready yet :( Cesar and myself traded of migration tasks over the course of the week: We fou

[Geotools-devel] Code Sprint 2018

Currently OSGEO is planning the 2018 Code sprint in Bonn Sunday-Sunday, March 18 to 25, 2018 (https://wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018) - there is some discussion as to whether this is the C-Tribe or if we should come together in a spirit of openness for one big sprint. Conns: We'd do tw

[Geotools-devel] Code sprint = dependency stomp

If there is any interest in a geotools code sprint at foss4g I would be happy to organize around stomping dependencies. We have an initial shortlist: - JDOM - vecmath - JSR-275 - update various jars :) - apache commons vs guava fight ( this one for Gabriel ) There are a number of dependencies w

Re: [Geotools-devel] code sprint - factory lookup replacement

> - Jody to start assembling GeoTools OSGi manifests I'm sorry that I did not follow up on this over the last two months. I did not find enough time to work on our Java GIS projects. I'm still very interested in this, and therefore by what you suggest here > - have (justin?) charge on ahead with

[Geotools-devel] code sprint - factory lookup replacement

Okay I am getting really keen to have a geotools code sprint - on the topic of a "lookup" class for GeoTools similar in spirit to the netbeans one. This would enable: - Justin to hook in some Python datastores for GeoServer - Jody to start assembling GeoTools OSGi manifests The plan would be to:

Re: [Geotools-devel] Code Sprint

Pieter, Geomaja seems an awesome project, congrats to the thorough documentation and examples! Will test it with the new Neo4j-Spatial GeoTools support when I get some time ... Cheers, /peter neubauer COO and Sales, Neo Technology GTalk:      neubauer.peter Skype       peter.neubauer Phone     

Re: [Geotools-devel] Code Sprint

Jody, this might not be entirely relevant to your question, but the Geomajas team will be looking into some kind of Geomajas-Datastore for GeoTools. The idea is to make it possible for GeoTools/GeoServer to connect to a Geomajas instance. Jody Garnett schreef: Is anyone interested in doing

[Geotools-devel] Code Sprint

Is anyone interested in doing a code sprint at foss4g this year? In the past we have split up by project, and then done some geotools hacking after the formal event. Jody Begin forwarded message: > From: Lorenzo Becchi > Date: 18 August 2010 1:18:38 AM AEST > To: OSGeo Discussions , foss4g2...

[Geotools-devel] Code Sprint

Day 1 -- We started transition by "excluding" the usual GeoTools Feature and implementation classes from our build; and then went around fixing the compile errors. Or we would of liked to but Internet / SVN access was spotty. We relocated after lunch to Refractions and proceeded to hack unt