Please, reopne the ticket, I will see what I can do to make use of one
of the standard jars on the jsr-275 website.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
ph
Good point about unsupported/jdbc - we do not want to change the
module name. We should leave the implementations that are not ready
yet where they are.
Slightly off topic (I saw Andrea mention this on the user emaillist).
One of the tasks associated with moving a module to supported is
running it
Another to probably mention is that we probably don't want to move all
of the modules over just yet. For instance mysql and sqlserver don't use
spatial indexing as of yet, so until they do they probably are not ready
for prime time, so we could just keep them in unsupported for the time
being.
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 plugi
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
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
Bedw
[
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 on
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
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 r
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
Geotools-devel@list
seems to have come good again..
On Thu, Jul 2, 2009 at 2:28 PM, Ben
Caradoc-Davies wrote:
> 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-sch
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
Software Engineer, CSIRO Exploration and M
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
Software Engineer, CSIRO E
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
Geotools-devel@lists.sourceforge
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 jai-tools
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)
Date: 2009/7/2
Subject: [jira] Commented: (GEOT
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
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
--
___
Geotools-d
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
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 wor
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 Giannecc
Metadata is include an old build of that project.
I just switched to the published API, adding this dependency:
javax.measure
jsr-275
1.0.0
then rebuilt. Everything worked for me, therefore I am going to apply
this change to trunk then sit and wait it
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 address
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 a
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1754/changes
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists
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 ad
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 Aime
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1753/changes
Changes:
[simonegiannecchini] working on GEOT-2569
--
[...truncated 4295 lines...]
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryT
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
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
Software Engineer, CSIRO Explo
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 shapefil
"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 ke
Andrea Aime ha scritto:
> 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
> o
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 eclipse:
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
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
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 org.geoto
37 matches
Mail list logo
