Ahh... I did not notice that they were not ... so that makes sense then why the CRS subsystem was mis behaving.
And yes, I manually modified the pom on the server to figure out why the tests were failing. Changed back and happy to report the build is happy again. -Justin Gabriel Roldan wrote: > Hi Justin, > > for the time being I've made the new tests to extend from > GeoServerAbstractTestSupport as a workaround. It should work, but now > hudson is complaining there's a conflict when it svn updated the wms > pom.xml. > I guess that's because you changed it manually while figuring out what > happens under different build environments. If so please revert the pom > so hudson can run the build. > > cheers, > Gabriel > Justin Deoliveira escribió: >> Hi all, >> >> Dwins and I have been trying to nail down why tests are failing on the >> build server and not on our local machines. Actually its worse than that: >> >> * build server via hudson -> FAIL >> * build server from command line -> PASS >> * local machine via eclispse -> FAIL >> * local machine from command line -> PASS >> >> The error in eclipse i get is the same as via hudson so I did some >> debugging. Basically what this boils down to is re-projection that is >> occurring between long-lat and lat-long when it should not be. Trying >> to figure out why I got lost and am left with a number of questions >> for Andrea since he is really the only one who understands how it all >> works :). >> >> So... Andrea: >> >> On GeoServer startup we set a few hints which tell the CRS subsystem >> "stuff". Basically my understanding is we tell it 2 things: >> >> 1. We set the XY "hint" >> 2. We then force certain factories (http) to honor the hint >> >> So... my question is what should be the result after this happens? My >> understanding is: >> >> CRS.decode( "EPSG:4326" ) -> XY >> CRS.decode( "http://.../epsg.xml#4326"; ) -> XY >> CRS.decode( "urn:...." ) -> YX >> >> Is this correct? >> >> My second question is how this relates to testing. Now this is just a >> guess but my impression of why we get such different results in >> different running configurations is because tests are running in >> different order. And on top of that we are throwing one-time setup >> testing into the mix. I wonder if there is just some cleanup that is >> not happening... like resetting of those global hints or something. >> Just a guess... i am kind of reaching at this point. >> >> It might be nice to be able to turn off one-time testing by flipping a >> switch. Just to rule out such situations where errors are occurring >> due to the sharing of test context. Especially since these failures do >> not apply to an actual instance of GeoServer. Any chance this is >> easily possible? >> >> > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- 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 Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
