Thanks very much Jody.
Michael
On Feb 14, 2008 1:40 PM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> The shapefile read/write support is known to deadlock on 2.4.0, a
> rewrite has been made for trunk (ie GeoTools 2.5) and we are waiting on
> community review and feedback.
>
> Looking at the test it
The shapefile read/write support is known to deadlock on 2.4.0, a
rewrite has been made for trunk (ie GeoTools 2.5) and we are waiting on
community review and feedback.
Looking at the test it makes use of wait(500) a fair bit - trying to
sleep for a set amount of time and verify that the lock h
Hello all,
I am new to this list and to geotools. In attempting to build the
2.4.0 sources (downloaded yesterday) on Mac OSX I receive the
following test failure:
Running org.geotools.data.shapefile.LockTest
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.014
sec <<< FAILURE!
> This is an interesting topic and I didn't wanted to bring it to the scene
> until I finally take the time to write down my robustness plan for geoserver,
> but yeah, I found the parser raising a parsing thread on each call, which is
> a dangerous thing. Like it is in general a good approach f
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/244/changes
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/d
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/243/changes
Changes:
[jdeolive] only changing namespace when element is non abstract
--
[...truncated 712 lines...]
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.496 sec
R
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/242/changes
Changes:
[jgarnett] Darn hudson beat my commit; that is always going to happen since it
is so much faster than my box
--
[...truncated 725 lines...]
Tests run: 5, Failures: 0, Er
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/241/changes
Changes:
[jgarnett] Switch to java.util.concurrent
--
[...truncated 892 lines...]
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.geotools.re
Use mvn -U when you next build geotools
For those projects (hi uDig I am looking at you) making use of ANT:
-
http://lists.refractions.net/m2//org/opengis/geoapi/2.2-SNAPSHOT/geoapi-2.2-20080213.205056-9.jar
-
http://lists.refractions.net/m2//org/opengis/geoapi/2.2-SNAPSHOT/geoapi-2.2-20080
Hi Justin,
thanks for the prompt reply.
On Wednesday 13 February 2008 07:59:06 pm Justin Deoliveira wrote:
> Wow, those results are compelling. Indeed I thought before of basing the
> streaming parser on a pull parser... seemed more natural then the hack
> of creating a separate parsing thread.
T
Cool; removed - as usual code review is welcome. Will commit when my
maven build finishes...
Note: most of the hard work was done already when Shapefile data store
was reviewed some weeks back; we are still wondering how the rewrite
effects others ... so far it has been quiet.
Jody
> Jody Garne
As always I am concerned that Martin takes on too much stuff; of course
so do I but anyways ... moving over to JScience units took me 2 days
with a team of 3 last time I tried. Just in case anyone wants to
volunteer :-)
Cheers,
Jody
--
Wow, those results are compelling. Indeed I thought before of basing the
streaming parser on a pull parser... seemed more natural then the hack
of creating a separate parsing thread.
A 100 features taking up 606 MB seems out of hand though. Are you using
the xpath streaming method? That message
Jody Garnett a écrit :
> Can we loose the dependency on edu.oswego.concurrent now that we have
Sure! The decision is mostly yours since this dependency has been introduced by
the Refractions's "threaded EPSG factories" work from last summer :)
It has been introduced in org.geotools.util package
Hi Justin,
I've been working on getting the nsdi test server data rendering in udig by
using the StreamingParser in the WFS DataStore, and got it.
Yet, its leading to OOM errors on the first try. I have yet to run it inside a
profiler, though in the meantime I did a quick (simple) feature parse
Adrian Custer ha scritto:
...
> Also, yes Martin is planning on moving geotools over to JScience units.
> Possibly right after he finishes his coverage work, his new renderer and
> brings peace to the world and hot chocolate to allmmm, hot
> chocolate. Okay, maybe in between some of that...
Wo
On Wed, 2008-02-13 at 10:02 -0800, Jody Garnett wrote:
> Good eye - you are right;
>
> The question still stands - as far as I can tell jsr108 is a jar martin
> makes up for us because he is kind. We could probably
> lose jsr 108 and switch to JScience but we will need to wait to hear
> from Ma
Jody Garnett a écrit :
> The question still stands - as far as I can tell jsr108 is a jar martin
> makes up for us because he is kind. We could probably
> lose jsr 108 and switch to JScience but we will need to wait to hear
> from Martin.
It was planned since a long time - I'm also on the JSR-27
Good eye - you are right;
The question still stands - as far as I can tell jsr108 is a jar martin
makes up for us because he is kind. We could probably
lose jsr 108 and switch to JScience but we will need to wait to hear
from Martin.
Jody
> Isn't that coming in from units (aka jsr 108)? If so,
I am using my new friend (mvn dependency:tree) to answer a couple common
questions for the user guide (ie. what jars do I need?)
When trying to answer that question for epsg-hsql I get the following tree:
>
> Building EPSG Au
+1 for geotools from me (I have no vote for GeoServer)
--
Ian Turton
http://www.geotools.org
http://pennspace.blogspot.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008
XML-XSD is not thread safe
--
Key: GEOT-1706
URL: http://jira.codehaus.org/browse/GEOT-1706
Project: GeoTools
Issue Type: Bug
Components: ext xml-xsd
Affects Versions: 2.5-M0
Reporter: Andrea
22 matches
Mail list logo
