I just checked out 2.3-M1 from svn to build it locally and grab the
sources, but after installing it i ran into compile issues, in api
stating that ReferencedEnvelope.getArea() does not exist.
Removing locally and downloading from the maven repo gives me my build
back. Question is why are the
Hello,
I got the following Exception thread if calling CRS.lookupEpsgCode in multible
treads.
Exception in thread pool-2-thread-3
org.geotools.factory.RecursiveSearchException: Recursive call while creating a
'FactoryUsingWKT' object.
at
Frank Gasdorf ha scritto:
Hello,
I got the following Exception thread if calling CRS.lookupEpsgCode in
multible treads.
Exception in thread pool-2-thread-3
org.geotools.factory.RecursiveSearchException: Recursive call while creating
a 'FactoryUsingWKT' object.
at
Oracle-NG does not properly load points
---
Key: GEOT-2584
URL: http://jira.codehaus.org/browse/GEOT-2584
Project: GeoTools
Issue Type: Bug
Components: data jdbc-ng
Environment: Windows
Was bin intentionally kept out of target so that it is not susceptible
to being wiped out in a mvn clean? I can see pros and cons both ways I
suppose.
The other nice thing about putting it under target is would be it gets
caught by svn:ignore, currently when I do an svn st i get all the bin
Justin Deoliveira ha scritto:
Was bin intentionally kept out of target so that it is not susceptible
to being wiped out in a mvn clean? I can see pros and cons both ways I
suppose.
Eclipse goes mad when someone fiddles with its class files and, at least
on my pc, I had to do a mvn
mvn clean in the eclipse environment is Clean all Projects. In my
opinion, it is not a good idea to mix these two kinds of building.
Things are easier to understand if mvn does its own build/clean and eclipse
does its own build/clean.
Justin Deoliveira writes:
Was bin intentionally kept
Hi all (hey Jesse),
the current shapefile datastore factory has this nasty habit of
caching the returned datastores so that the hitting it twice
with the same parameters will return the same datastore.
This seems downright wrong, it's not depanded by the datastore
SPI and breaks disposing
I am now getting unit test failures that pass in maven and used to pass
in Eclipse. I suspect modules using testResources might be affected.
Eclipse may have been relying on maven testResources to set up the
classpath with everything in it.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Ben Caradoc-Davies wrote:
I am now getting unit test failures that pass in maven and used to pass
in Eclipse. I suspect modules using testResources might be affected.
Eclipse may have been relying on maven testResources to set up the
classpath with everything in it.
I retract that: the
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1753/changes
Changes:
[simonegiannecchini] working on GEOT-2569
--
[...truncated 4295 lines...]
at
I thought we addressed this already? Perhaps only on trunk ...
The good reason was that we were unable to trust our user community to
hold onto a datastore instance; and two datastores both attacking the
same shapefile can result in some trouble.
Jody
On Wed, Jul 1, 2009 at 6:41 PM, Andrea
Jody Garnett ha scritto:
I thought we addressed this already? Perhaps only on trunk ...
The good reason was that we were unable to trust our user community to
hold onto a datastore instance; and two datastores both attacking the
same shapefile can result in some trouble.
Yeah, it was
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1754/changes
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
Hello. Recently I have debugged ShapefileReader with one shapefile that
caused rendering problems in UDIG from 1.1.x codebase. The shapefile is
generated by las2ogr utility taking LiDAR file (points cloud in (X,Y,Z)
space) as an input. Actually points are written to shapefile by OGR (I
use
And an equal amount of trouble is caused by users calling dispose() on a
shapefile DS, not knowing it is cached, and blowing away open locks if
something else has it open as well. GEOT-2569 shows what happens if we
throw finalizers into the mix. Hairy.
Jody Garnett wrote:
I thought we
Metadata is include an old build of that project.
I just switched to the published API, adding this dependency:
dependency
groupIdjavax.measure/groupId
artifactIdjsr-275/artifactId
version1.0.0/version
/dependency
then rebuilt. Everything worked for
Update jsr-275 to 1.0.0 version
---
Key: GEOT-2586
URL: http://jira.codehaus.org/browse/GEOT-2586
Project: GeoTools
Issue Type: Improvement
Components: core metadata
Reporter: Simone
Hi Andrea / Michael:
I sent you both a patch yesterday that explored the idea of
correcting the URL inside the ShapefileDataStore and
ShapefileDataStoreFactory; I still had to run around and fix a lot of
the test cases ... but everything did build.
Today I have a better idea; but no time to work
Decimator fails to decimate 3d points
-
Key: GEOT-2585
URL: http://jira.codehaus.org/browse/GEOT-2585
Project: GeoTools
Issue Type: Bug
Components: core main
Affects Versions: 2.5.6
Thanks Jody.
I'm feeling a bit confused now. Is File.toURI().toURL() definitely
broken in the latest mac java ?
Will wait for the next instalment :)
Michael
--
___
Simone,
I am getting transitive dependency problems resulting in Eclipse build
failures. I think the problem might be that 1.0.0 is a relocation to
0.9.1, but some modules use 1.0-beta-2. Eclipse dependency mangling
gives a random ordering of dependencies, so modules expecting 1.0-beta-2
fail
Hello,
Any objections if the work mentioned below is merged into trunk ? The
only change affecting other modules is that Process.execute now throws
an exception.
cheers
Michael
-- Forwarded message --
From: Michael Bedward (JIRA) j...@codehaus.org
Date: 2009/7/2
Subject:
A brief update for the list and Steve...
I've proposed to merge the process module working branch into trunk.
This will provide vector to raster conversion for users with the
constraint that generated coverages have to fit into memory.
I've begun building a disk-based tile cache for the
Hi Ben,
Is that an Eclipse-specific problem ? Today's build goes ok for me
with mvn from the shell.
Michael
--
___
Geotools-devel mailing list
RobA and I are both seeing this:
svn: Commit failed (details follow):
svn: connection refused by the server
svn: OPTIONS request failed on
'/geotools/trunk/modules/unsupported/app-schema/app-schema/src/test/java/org/geotools/data/complex/config'
--
Ben Caradoc-Davies
Michael Bedward wrote:
Is that an Eclipse-specific problem ? Today's build goes ok for me
with mvn from the shell.
Yes, but even maven will have multiple instances of the jar, but with
1.0-beta-2 first, so it works in maven.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software
seems to have come good again..
On Thu, Jul 2, 2009 at 2:28 PM, Ben
Caradoc-Daviesben.caradoc-dav...@csiro.au wrote:
RobA and I are both seeing this:
svn: Commit failed (details follow):
svn: connection refused by the server
svn: OPTIONS request failed on
So just changing metadata to reference the top pom like all the other
modules do for jsr is all that is required ?
Michael
--
___
Geotools-devel mailing list
Michael Bedward wrote:
So just changing metadata to reference the top pom like all the other
modules do for jsr is all that is required ?
Yes, this fixes the problem. metadata did use the top-level pom. This
was changed in GEOT-2586. The fix is to revert the GEOT-2586 change.
Simone, can I
I have been working through some jdbc-ng issues lately in an effort move
it to supported. There are currently two critical bugs outstanding:
http://jira.codehaus.org/browse/GEOT-2488
Has a patch, but it needs work.
http://jira.codehaus.org/browse/GEOT-2231
This one has a patch awaiting review
[
http://jira.codehaus.org/browse/GEOT-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies reopened GEOT-2586:
--
This change breaks the build in Eclipse because there are multiple versions of
the JSR-275 jar
File.toURI().toURL() is definitely broken in the latest mac release.
Fortuantly it is broken in the same way as file.toURL() - so it is
very sensible for our code to project against an invalid URL by doing
a couple clean up attempts before hand.
Jody
On Thu, Jul 2, 2009 at 1:39 PM, Michael
Hi Justin:
The plan sounds fine - and congradulations :-)
My question is where to put the individual bits. Here is what I had in mind:
* Move the contents of unsupported/jdbc-ng/jdbc-core into library/jdbc
* Move the plugins from unsupported/jdbc-ng/* to plugin/jdbc/*
* Move the old jdbc
Jody Garnett wrote:
Hi Justin:
The plan sounds fine - and congradulations :-)
My question is where to put the individual bits. Here is what I had in mind:
* Move the contents of unsupported/jdbc-ng/jdbc-core into library/jdbc
* Move the plugins from unsupported/jdbc-ng/* to plugin/jdbc/*
35 matches
Mail list logo
