See http://hudson.opengeo.org/hudson/job/geotools-trunk/932/changes
Changes:
[simboss] -minor improvements
[simboss] -renamed CoverageFormatFactory
--
[...truncated 3615 lines...]
at
org.geotools.gce.imagepyramid.ImagePyramidReader.read(ImagePyra
See http://hudson.opengeo.org/hudson/job/geotools-trunk/933/changes
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
It seems the svn is down again, as well as lists.refractions.net
and udig.refractions.net
Cheers
Andrea
Ben Caradoc-Davies ha scritto:
> All fixed. They did get my email.
>
> Chris Hodgson advises:
> "Fixed.
> Weird CLOSE_WAIT overflow issue, again...
> Chris"
>
>
> Ben Caradoc-Davies wrote:
>>
Support non serial primary keys in JDBCDataStore
Key: GEOT-1959
URL: http://jira.codehaus.org/browse/GEOT-1959
Project: GeoTools
Issue Type: Improvement
Components: data h2
JDBCFeatureStore should simplify filters after splitting them
-
Key: GEOT-1960
URL: http://jira.codehaus.org/browse/GEOT-1960
Project: GeoTools
Issue Type: Improvement
Com
Hi Jody,
thanks for trying the release out
On Monday 25 August 2008 02:03:50 am Jody Garnett wrote:
> Hi Gabriel; thanks for all the hard work (and for including an export of
> the user guide)!
>
> I downloaded the source code (now called "project") from SF and started
> a build:
>
> 1. This relea
JDBCDataStore should use prepared statemetns for all database operations
Key: GEOT-1961
URL: http://jira.codehaus.org/browse/GEOT-1961
Project: GeoTools
Issue Type: Imp
Allow sql dialects to specify their own sql encoder
---
Key: GEOT-1962
URL: http://jira.codehaus.org/browse/GEOT-1962
Project: GeoTools
Issue Type: Improvement
Components: data h2
Base JDBC datastore factory should allow minimal control over the connection
pool
-
Key: GEOT-1963
URL: http://jira.codehaus.org/browse/GEOT-1963
Project: GeoTools
JDBCDataStoreFactory should use gt2 wise default factories
--
Key: GEOT-1964
URL: http://jira.codehaus.org/browse/GEOT-1964
Project: GeoTools
Issue Type: Bug
Components: data
Hi,
lists.refractions.net hangs out for me.
could you check it?
TIA,
Gabriel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win gr
JDBC*Test classes assume lowercase and mixed case names are valid
-
Key: GEOT-1965
URL: http://jira.codehaus.org/browse/GEOT-1965
Project: GeoTools
Issue Type: Bug
Com
Jody Garnett ha scritto:
> Nothing went wrong that I know of; my impression was Jesse stalled
> waiting for feedback. Do you want to try a read/write lock?
In fact I already tried with a crude patch, just to get an idea.
The main problem with using
http://java.sun.com/j2se/1.5.0/docs/api/java/ut
I have set up a proposal here:
- http://docs.codehaus.org/display/GEOTOOLS/Move+to+another+Server
We have talked about moving to another server - the above is a proposal
to do so. This proposal is not going to go anywhere with out volunteer
time to make it happen; if you can help with any of th
Andrea Aime wrote:
> I was wondering, is that (grabbing the write lock while still
> possessing a read lock) supposed
> to be happening, or is it just a bug in how the lock calls are being
> made?
It was intensional; we need to actually read the shapefile in order to
make a copy of it (ie in o
PropertyExistsFunction blows up GeoServer shapefile usage on IBM JDK
Key: GEOT-1966
URL: http://jira.codehaus.org/browse/GEOT-1966
Project: GeoTools
Issue Type: Bug
XMLConverterFactory should avoid doing expensive operations if the target type
is not the one it can handle
---
Key: GEOT-1967
URL: http://jira.codehaus.org/br
Hi,
I'm wondering if all the synchronized keywords around the
getXXXFactory methods of CommonFactoryFinder are really needed.
Wouldn't it be sufficient to syncrhonize the creation of the
the service registry, that is, the getServiceRegistry?
Scanning the registry takes quite a bit more time that ju
Shapefile rendering feature building efficiency can be improved
---
Key: GEOT-1968
URL: http://jira.codehaus.org/browse/GEOT-1968
Project: GeoTools
Issue Type: Improvement
Andrea Aime a écrit :
> I'm wondering if all the synchronized keywords around the
> getXXXFactory methods of CommonFactoryFinder are really needed.
> Wouldn't it be sufficient to syncrhonize the creation of the
> the service registry, that is, the getServiceRegistry?
> Scanning the registry takes q
Gabriel,
please also update the Eclipse formatter.xml on the 2.4.x branch.
You could encourage adoption of these Eclipse formatter settings by
adding a paragraph to:
http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions
(or the Eclipse pages)
It would be even nicer if "mvn eclipse:ecl
21 matches
Mail list logo
