Ben Caradoc-Davies ha scritto:
The GeoTools module gt-app-schema has now been included in GeoServer
releases since October 2009. I propose to promote it (and the proposed
gt-app-schema-resolver) to extension. The old unsupported/app-schema
will remain to house gt-webservice and other
Ben Caradoc-Davies ha scritto:
I propose to split off the application schema resolution code from
gt-app-schema into a new module gt-app-schema-resolver:
http://jira.codehaus.org/browse/GEOT-3085
Any objections?
The new module has no dependencies on gt-app-schema. If
Ben Caradoc-Davies ha scritto:
On 18/05/10 09:22, Ben Caradoc-Davies wrote:
So, if I announced that I had a third-party whizbang-1.3.2.jar that I
wanted to use in app-schema testing, would I be allowed to upload it to
the osgeo maven repo? I think the process has been fairly informal so far.
Andrea Aime ha scritto:
Ben Caradoc-Davies ha scritto:
On 18/05/10 09:22, Ben Caradoc-Davies wrote:
So, if I announced that I had a third-party whizbang-1.3.2.jar that I
wanted to use in app-schema testing, would I be allowed to upload it to
the osgeo maven repo? I think the process has been
On 18/05/10 14:38, Andrea Aime wrote:
How is the test coverage?
OK. All encoding test are in GeoServer.
Is it a single module or multimodule?
Multiple. gt-app-schema, gt-app-schema-resolver (coming soon),
gt-sample-data-access (for testing).
You are the maintainer for all of them?
Yes.
Ben Caradoc-Davies ha scritto:
On 18/05/10 14:38, Andrea Aime wrote:
How is the test coverage?
OK. All encoding test are in GeoServer.
Is it a single module or multimodule?
Multiple. gt-app-schema, gt-app-schema-resolver (coming soon),
gt-sample-data-access (for testing).
You are
On 18/05/10 14:39, Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
The new module has no dependencies on gt-app-schema. If
gt-app-schema-resolver works well enough, it might be useful elsewhere.
It will be used initially by gt-app-schema only.
Sounds good to me. I'm just wondering about
Ben Caradoc-Davies ha scritto:
On 18/05/10 14:39, Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
The new module has no dependencies on gt-app-schema. If
gt-app-schema-resolver works well enough, it might be useful elsewhere.
It will be used initially by gt-app-schema only.
Sounds good to
On 18/05/10 16:11, Andrea Aime wrote:
Ok, this goes against the graduation rules, you don't have the necessary
testing coverage.
So, I thought, why am I waving my hands when I should be measuring the
coverage? Turns out it is much better than I thought (gt-app-schema on
trunk, before
On 18/05/10 14:49, Andrea Aime wrote:
I don't think you really need permission, especially for a non core
module.
If it was main, renderer or something a lot of people depend onto
I would expect some discussion before adding a dependency, but
otherwise I don't think you really need to ask
I view this as one of the stars we use to evaluate things (ie things we care
about as a community) rather then a complete down check.
The fact that the coverage is being checked with a nightly build somewhere
means that any incidental breakage will be found out quickly right?
We do not demand
Jody Garnett ha scritto:
I view this as one of the stars we use to evaluate things (ie
things we care about as a community) rather then a complete down
check. The fact that the coverage is being checked with a nightly
build somewhere means that any incidental breakage will be found out
On 18/05/2010, at 10:44 PM, Andrea Aime wrote:
Jody Garnett ha scritto:
check. The fact that the coverage is being checked with a nightly
build somewhere means that any incidental breakage will be found out
quickly right?
Coverage being checked nightly? This is news to me.
I though he
CoverageCrop: cropping by shape
---
Key: GEOT-3087
URL: http://jira.codehaus.org/browse/GEOT-3087
Project: GeoTools
Issue Type: Improvement
Components: core coverage
Reporter: Emanuele
make RenderingExecutor more flexible
Key: GEOT-3088
URL: http://jira.codehaus.org/browse/GEOT-3088
Project: GeoTools
Issue Type: Improvement
Components: ext mappane
Reporter:
add 'dirty rectangles' logic to JMapPane
Key: GEOT-3089
URL: http://jira.codehaus.org/browse/GEOT-3089
Project: GeoTools
Issue Type: Improvement
Components: ext mappane
16 matches
Mail list logo
