Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

On 11/08/15 12:00, Jody Garnett wrote: > Thanks Ben, I trust Stefano can return to his much deserved vacation. I hope so. While we appreciate those who work on their vacation and weekends, I cannot recommend it. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Thanks Ben, I trust Stefano can return to his much deserved vacation. -- Jody Garnett On 10 August 2015 at 16:33, Ben Caradoc-Davies wrote: > I am pleased to confirm that with this change on master, full GT+GWC+GS > builds pass, as do GS app-schema online tests against postgis. Great work > Ste

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

I am pleased to confirm that with this change on master, full GT+GWC+GS builds pass, as do GS app-schema online tests against postgis. Great work Stefano! Kind regards, Ben. On 11/08/15 10:20, Ben Caradoc-Davies wrote: > Did you run the GeoServer app-schema online tests? > > On 11/08/15 10:14,

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Did you run the GeoServer app-schema online tests? On 11/08/15 10:14, Jody Garnett wrote: > That seems very odd, my local build succeeded (so I will merge). -- Ben Caradoc-Davies Director Transient Software Limited New Zealand

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

That seems very odd, my local build succeeded (so I will merge). Lets start a new email thread about this temperamental Running GridCoverageTest failure. -- Jody Garnett On 10 August 2015 at 14:57, Stefano Costa wrote: > Hi Jody, > I'm attaching the stacktrace of one of the two failures I get

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Hi Jody, I'm attaching the stacktrace of one of the two failures I get building the Grid Coverage module (the second failure producing a similar stacktrace). Looks like it might be due to some network issue on my side? --S Il giorno lun, 10/08/2015 alle 14.37 -0700, Jody Garnett ha scritto: >

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Should be fine Stefano, especially with that javadoc warning. I sometimes name method like that as "internalMappings()" (assuming the by Names is obvious from the type signature). I am a bit concerned about "weird failures" in unrelated modules since I am trying to catch up and merge all the pull

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Hi, pull request with the fix is here: https://github.com/geotools/geotools/pull/932 All unit tests in the app-schema extension pass, I couldn't try a full build because of some weird failures in other unrelated modules. The fix contains a small API change: I renamed the getMappingByElement() met

Re: [Geotools-devel] Delaying current releases

CCing the GWC devel list since this will push back the 1.8-beta and feature freeze as well. On 10 August 2015 at 11:08, Jody Garnett wrote: > Agreed. Let's stick with your plan. > > I can probably get the same effect with a blog post linking to nightly > build. > > I am on the road next week so

[Geotools-devel] [JIRA] (GEOT-5190) General Oblique Transform for Rotated Pole Coordinates

Title: Message Title Jody Garnett [Administrator] created an issue

Re: [Geotools-devel] Call For Vote: Frank Gasdorf has requested commit access

+1 Frank is familiar with our developers guide and has submitted lots of fixes over the years. Welcome Frank :) -- Jody Garnett On 10 August 2015 at 04:25, Ben Caradoc-Davies wrote: > I vote +1 for GeoTools commit access for Frank Gasdorf. Frank has been an > active contributor to GeoServer, G

Re: [Geotools-devel] Delaying current releases

Agreed. Let's stick with your plan. I can probably get the same effect with a blog post linking to nightly build. I am on the road next week so I would still ask that API changes be submitted this week if possible so I can give them my full attention. On Mon, Aug 10, 2015 at 11:04 AM Simone Giann

Re: [Geotools-devel] Dropping CollectionSource?

On Mon, Aug 10, 2015 at 7:51 PM, Jody Garnett wrote: > Yeah, we brought that in for some grad students that did not stick with > the project. > > Should be able to remove some associated functionality, like Filter > property access for java beans. > Meh, I'd keep that one (the bean property acce

Re: [Geotools-devel] Delaying current releases

Ciao Jody, I will discuss this with Andrea tomorrow but at a first glance falling back onto two releases might simply mean more work with no real gain. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone

[Geotools-devel] [JIRA] (GEOT-5189) Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess

Title: Message Title Stefano Costa created an issue

Re: [Geotools-devel] Incoherent getNames() and getFeatureSource() behavior in AppSchemaDataAccess?

Hi all, being officially on vacation, I finally found some spare time to look into this :-) I was able to write a unit test showing the issue: @Test public void testGetNamesAndFeatureSources() throws Exception { /* * Initiate data accesses and make sure they have the mappings */

Re: [Geotools-devel] Dropping CollectionSource?

Yeah, we brought that in for some grad students that did not stick with the project. Should be able to remove some associated functionality, like Filter property access for java beans. -- Jody Garnett On 10 August 2015 at 02:35, Andrea Aime wrote: > Hi, > I've just noticed the CollectionSource

Re: [Geotools-devel] Delaying current releases

Morning Simone, It would of course be nice to have a release in hand for foss4g (the reason for our september release cycle) but I understand the delay. Checking in with developers here and both Kevin and Torben have some API changes that would be easier with an extra bit of time. So a +1 from th

Re: [Geotools-devel] Add support for DB specific temporal models

On Mon, Aug 10, 2015 at 2:38 PM, Christian Mueller < christian.muel...@os-solutions.at> wrote: > Hi all > > @Jody. Using DB2 I could detect which tables and columns participate in > temporal support. I could implement the logic behind the scenes, no public > API change necessary. I only wanted to

Re: [Geotools-devel] Add support for DB specific temporal models

Hi all @Jody. Using DB2 I could detect which tables and columns participate in temporal support. I could implement the logic behind the scenes, no public API change necessary. I only wanted to ask if we should make a concept for all jdbc data stores. @Andrea Of course you could have timestamps in

[Geotools-devel] Delaying current releases

Dear All, I wanted to ask the other member how do they feel about temporarily delaying the releases for GS 2.8 and GT 14. Most people on our side are on vacation in the next two weeks (Mauro, Stefano, Daniele and partially Andrea and Alessio to name a few) moreover, judging by the number of foreig

[Geotools-devel] Call For Vote: Frank Gasdorf has requested commit access

I vote +1 for GeoTools commit access for Frank Gasdorf. Frank has been an active contributor to GeoServer, GeoTools, and uDig for ages. All committers may vote: http://docs.geotools.org/latest/developer/roles/committer.html#process On 10/08/15 20:26, Frank Gasdorf wrote: > At the moment I cannot

Re: [Geotools-devel] pull request 924 - what's next?

Frank, these are orthogonal concerns. CLAs are copyright assignment, whereas commit access is authorisation to move bits into a particular repository. Since the migration to GitHub, it is much easier to get things done without commit access. However, commit access makes work easier. Your reque

[Geotools-devel] Dropping CollectionSource?

Hi, I've just noticed the CollectionSource class has been basically unused for years, all the usage points for it have been tapped years ago (more than our git history holds): https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/map/DefaultMapContext.j

Re: [Geotools-devel] pull request 924 - what's next?

Jody, thanks for the merge and explaination. I'm wondering whether there is a different between a signed CLA and commit access. At the moment I cannot commit into geotools whereas I can modify geoserver repositiory. Do I have to request commit access for geotools too? If so I'm do this hereby. Th

Re: [Geotools-devel] pull request 924 - what's next?

If you have made contributions to geoesrver, than you have already signed the paperwork (it is the same for both projects as they are both members of OSGeo). -- Jody Garnett On 10 August 2015 at 00:27, Frank Gasdorf wrote: > Hello everybody, > > I'd like to know whether I have to sign a CLA to

[Geotools-devel] pull request 924 - what's next?

Hello everybody, I'd like to know whether I have to sign a CLA to get a pull request (docs only) merged into codebase. During an upgrade to geotools 11.2 (uDig based project) I stumbled about the datastore docs (code example). https://github.com/geotools/geotools/pull/924 Thanks in advance - Fra