Looking into the xerces version hell for a bit; the root pom explicitly has
2.4.0 in the dependency management section.
GeoTools meanwhile has 2.7.1 - so my guess is most of the modules get xerces as
a transitive dependency; and main that actually uses it directly is the odd
fish out.
Blame provides the following for geotools:
59fbd7d9 (acuster 2008-05-08 15:02:00 +0000 862) <version>2.7.1</version>
And the following for geoserver:
a86653f4 geoserver/pom.xml (jdeolive 2007-02-07 04:10:33 +0000 572)
<version>2.4.0</version>
So this appears to be a long standing issue? Any idea why it is hitting us
today...
--
Jody Garnett
On Sunday, 19 June 2011 at 3:06 PM, Jody Garnett wrote:
> Thanks David; I was just stressing over the xerces version conflict (trying
> to test geotools patches against geoserver). Please commit :-)
> It is hard to cut down on networking going on during units tests; some
> classes like URL like to hit the network for hashcode and equals etc...
>
> --
> Jody Garnett
>
>
> On Sunday, 19 June 2011 at 12:50 PM, David Winslow wrote:
>
> > Hi all,
> >
> > I've been having test failures locally on geoserver trunk for some time,
> > but since I am not all that active there and no one else seems to be
> > complaining I didn't bring it up on the list. Today I finally found some
> > time to investigate, and actually found two issues. Now I get all tests
> > passing :)
> > xerces version conflict - For most modules in GeoServer is identifying
> > xercesImpl 2.6.2 as the correct one to include on the classpath, however
> > for org.geoserver:main it is using 2.4.0. This is causing
> > AbstractMethodError's at runtime, as you might expect. I tried bumping the
> > version in geoserver's main pom to 2.6.2 and tests pass, any objections to
> > committing it?
> > networking in coverage setup - this one is a little weird... redhat based
> > systems like my fedora laptop have a weird glitch where setting a custom
> > hostname during the install process doesn't necessarily update the
> > /etc/hosts file, then some programs have issues when "myname.localdomain"
> > doesn't resolve. The JVM seems to be one of those programs. Ok, so I fixed
> > my hosts file. The weird part is that I was running into those errors
> > during setup of coveragestores in mock data directories for GeoServer's
> > unit tests, should there be networking going on during this operation? I'm
> > attaching a stack trace for one of the failing tests to this mail.
> >
> >
> > --
> > David Winslow
> > OpenGeo - http://opengeo.org/
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > (mailto:Geoserver-devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> > Attachments:
> > - org.vfny.geoserver.ProjectionPolicyTest.txt
> >
> >
>
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
