On Fri, Dec 7, 2012 at 10:57 PM, Alex Trofast alex.trof...@actian.comwrote:
Hello all,
** **
Working on the Ingres experimental plugin on Windows for the first time I
get test failures I don’t see on Linux. The exception is a
ClassCastException and the backtrace looks like this:
See http://hudson.opengeo.org/hudson/job/geotools-master/4637/
--
This message is automatically generated by Hudson.
For more information on Hudson, see: http://hudson-ci.org/
--
LogMeIn Rescue: Anywhere, Anytime
Hi Andrea,
Ok good to know it's on my end, do you have any ideas why this
particular part might fail, only on Windows and not on Linux with my
driver?
Thanks!
Alex
From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of
Andrea Aime
Sent: December-09-12 4:02 AM
To: Alex
On Sun, Dec 9, 2012 at 12:06 PM, Alex Trofast alex.trof...@actian.comwrote:
Hi Andrea,
** **
Ok good to know it’s on my end, do you have any ideas why this particular
part might fail, only on Windows and not on Linux with my driver?
Hmm... not really, but I've spent a few weekends
To Alex,
Are you sure that this is complete stacktrace? I don't see a getAttribute line
in the stacktrace; the getAttribute line you highlighted.
To Andrea,
The stacktrace looks a little like unit testing for MySQL. Is testing for MySQL
enabled on your windows machine?
Brett Walker
Sent
Andrea,
That should have been Ingress not MySQL
Brett
Sent from my iPad
On 09/12/2012, at 10:35 PM, Brett Walker
brett.wal...@geometryit.commailto:brett.wal...@geometryit.com wrote:
To Alex,
Are you sure that this is complete stacktrace? I don't see a getAttribute line
in the stacktrace;
Hi Brett,
Seems like it got cut off I think, here’s the full one:
java.lang.ClassCastException: java.lang.String cannot be cast to
com.vividsolutions.jts.geom.Geometry
at
org.geotools.jdbc.JDBCDataStore.insertSQLPS(JDBCDataStore.java:3688)
at
On Sun, Dec 9, 2012 at 12:35 PM, Brett Walker
brett.wal...@geometryit.comwrote:
To Alex,
Are you sure that this is complete stacktrace? I don't see a getAttribute
line in the stacktrace; the getAttribute line you highlighted.
To Andrea,
The stacktrace looks a little like unit testing for
See http://hudson.opengeo.org/hudson/job/geotools-master/4640/changes
Changes:
[Jody Garnett] Add JTS.toGeographic
[Jody Garnett] Allow property files to work with 3D data again
[Jody Garnett] Connect JTS.toGeographic up to StreamingRenderer allowing 3D
content to be displayed
[Jody Garnett]
See http://hudson.opengeo.org/hudson/job/geotools-master/4641/changes
Changes:
[Andrea Aime] Fixing test expectations, the property is geometryless so the
bounds of it must be empty
--
[...truncated 5731 lines...]
at
See http://hudson.opengeo.org/hudson/job/geotools-master/4642/changes
Changes:
[Andrea Aime] Have decimation work in case no transformation is provided
--
[...truncated 5730 lines...]
at
See http://hudson.opengeo.org/hudson/job/geotools-master/4643/
--
[...truncated 5680 lines...]
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at
See http://hudson.opengeo.org/hudson/job/geotools-master/4644/changes
Changes:
[Jody Garnett] Fine grain testing to look into failure on hudson
--
[...truncated 5737 lines...]
at
Okay I am having a bad go at this - after working hard on a patch, asking
Andrea for review, getting the clear instructions not to break the build and
committing over the weekend .. the build is now broken. Trouble is it works
locally, and I am stuck committing, hitting go on hudson, and trying
Jody,
the build is passing for me locally and in Jenkins.
Might be test order (platform) dependent. What happens if you run just
that test with this in the root of gt-render?
mvn -o -Dtest=GeographicTransformPointTest test
Kind regards,
Ben.
On 10/12/12 11:59, Jody Garnett wrote:
Okay I am
Jody,
I can make this test fail by adding
runOrderreversealphabetical/runOrder
to the top-level pom surefire config. I then get:
Failed tests:
testBounds(org.geotools.renderer.lite.GeographicTransformPointTest):
expected:0.665264316713612 but was:NaN
Looks like test state is leaking. Axis
On December 10, 2012 13:59:43 Jody Garnett wrote:
b) the build boxes? Unlikely, but perhaps they are going multi-threaded on
me, or have more horse power and thus can show some problems I cannot see
locally.
I've just cleared out Hudson's working directory for geotools-master in the
event
See http://hudson.opengeo.org/hudson/job/geotools-master/4645/changes
Changes:
[Jody Garnett] Ignore test just to see the build go once
--
Started by user hudson
Started by an SCM change
Started by an SCM change
Checkout:workspace /
Thanks guys - I am going to look at defining using WKT for definition rather
than EPSG code so at least these tests can pass.
We may need to say straight up what axis order CRS has been configured with as
part of our testing guidelines.
--
Jody
Sent with Sparrow
Jody,
with runOrderreversealphabetical/runOrder in the top-level pom, I
brute forced all preceding tests paired with with
GeographicTransformPointTest. Either of SpatialFilterTest or
RenderingTransformationTest causes the failure.
That is, with runOrderreversealphabetical/runOrder, both of
Jody, I think the working directory is a red herring. The problem is the
axis order hints in the test fixtures. It is likely something is caching
a CRS built with the wrong hints.
On 10/12/12 13:22, Jody wrote:
Thanks guys - I am going to look at defining using WKT for definition
rather than
See http://hudson.opengeo.org/hudson/job/geotools-master/4646/
--
[...truncated 5675 lines...]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
Jody,
the attached fix plugs two hint leaks and makes the build pass with
alphabetical, reversealphabetical, and (my) filesystem order.
I am ready to commit now. I will contact you first to ensure you do not
have an alternative fix.
Kind regards,
Ben.
On 10/12/12 13:26, Ben Caradoc-Davies
See http://hudson.opengeo.org/hudson/job/geotools-master/4647/
--
[...truncated 5723 lines...]
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Jody,
I was not able to contact you. I have committed
2089d98fb823f8f9ebc5a52d7bb55b72e7d9a1a5 on master.
Kind regards,
Ben.
On 10/12/12 14:21, Ben Caradoc-Davies wrote:
Jody,
the attached fix plugs two hint leaks and makes the build pass with
alphabetical, reversealphabetical, and (my)
Jody,
the gt-render build is fixed on Hudson. (The rest is still running.)
Kind regards,
Ben.
On 10/12/12 14:31, Ben Caradoc-Davies wrote:
Jody,
I was not able to contact you. I have committed
2089d98fb823f8f9ebc5a52d7bb55b72e7d9a1a5 on master.
Kind regards,
Ben.
On 10/12/12 14:21, Ben
See http://hudson.opengeo.org/hudson/job/geotools-master/4648/changes
--
This message is automatically generated by Hudson.
For more information on Hudson, see: http://hudson-ci.org/
--
LogMeIn Rescue: Anywhere,
Jody,
the build is fixed.
The solution was similar to one I applied to gt-epsg-hsql in June:
https://jira.codehaus.org/browse/GEOT-4174
Kind regards,
Ben.
On 10/12/12 14:39, Ben Caradoc-Davies wrote:
Jody,
the gt-render build is fixed on Hudson. (The rest is still running.)
Kind regards,
Go for it Ben and thanks so much for the hussle!
--
Jody
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Monday, 10 December 2012 at 4:21 PM, Ben Caradoc-Davies wrote:
Jody,
the attached fix plugs two hint leaks and makes the build pass with
alphabetical, reversealphabetical,
I think I need to add that to the devel guide ;)
Thanks again Ben, Andrea, Benjamin.
--
Jody
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Monday, 10 December 2012 at 5:07 PM, Ben Caradoc-Davies wrote:
Jody,
the build is fixed.
The solution was similar to one I applied
On Mon, Dec 10, 2012 at 8:07 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Jody,
the build is fixed.
But... is it for good?
Some of the tests that were failing are simply marked @Ignore now?
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it
Niels,
I favour option 3 (new module gt-complex) because it does different
things to gt-app-schema-resolver, which builds no features or types, has
no dependency on gt-app-schema, and concerns itself with finding and
caching XSD documents and making them available to the gt-xsd-core
32 matches
Mail list logo
