A simple testcase to help us to see if this time we don't do another error could be a good thing...
thx.

I second the rating of this bug as critical. This bug breaks Eclipse integration for GeoTools, because maven-eclipse-plugin does not honour exclusions of transitive dependencies, and GeoTools Eclipse integration relies on xml-apis provided by the JRE being compatible with xerces 2.7 and being earlier on the classpath. Yes, this sucks, but it works.

To reproduce with Maven 2.0.10 (use a Java 5 JDK):

(1) svn co -r32785 http://svn.osgeo.org/geotools/trunk geotools-trunk

(2) cd geotools-trunk

(3) mvn -Dmaven.test.skip install eclipse:eclipse

(4) import into Eclipse, and see modules fail to compile

Workaround for this bug is to pin your project to version 2.5:

<build>
    <pluginManagement>
      <plugins>
        <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-eclipse-plugin</artifactId>
           <version>2.5</version>
 ...

See Nabble discussion:
http://n2.nabble.com/Eclipse-integration-broken--td2631438.html

this also broke my project. I have a dependency on mx4j (it's transitive and shouldn't appear on here, but that's a different bug).

It took a few frustrating hours to track down why I could not compile in Eclipse but could in Maven. Please revert this change. I have pinned to 2.5.1 for now.

Do not hesitate to vote for the issue. I always try to check them (http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.html#Maven%202.x%20Eclipse%20Plugin). For this issue, isn't there a different case for a jre container (which should be at the beginning) and others containers (which should be at the end to be able to override them MECLIPSE-442)

I would suggest to make this configurable. Most application servers can be configured to place their classes before or after application classes. But I agree that JRE classes must come first in any case.

How many votes does this have to have before it makes a release. Version 2.7 just came out and it still has the same incorrect classpath ordering for the JDK/JRE

I suspect that we need to get this assigned to someone. I will email the project lead.

GeoTools is still pinned to 2.5, and so it will remain until this bug is fixed.

Thanks, Barrie.