Maven 2.x Eclipse Plugin

MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath

Details

  • Number of attachments :
    0

Description

A patch was accepted into maven 2.6 as part of jira MECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar.

I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse

With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not.

Issue Links

This issue relates to:
MECLIPSE-581 Test source directories appear before Main source directories Major Closed
This issue is depended upon by:
MECLIPSE-605 JRE position in Eclipse generated classpath is different from the one used in Maven compiler Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Arnaud Heritier added a comment -

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

Show
Arnaud Heritier added a comment - A simple testcase to help us to see if this time we don't do another error could be a good thing... thx.
Hide
Permalink
Ben Caradoc-Davies added a comment - - edited

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

Show
Ben Caradoc-Davies added a comment - - edited 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
Hide
Permalink
Ben Caradoc-Davies added a comment -

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>
 ...
Show
Ben Caradoc-Davies added a comment - 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>
 ...
Hide
Permalink
Ben Caradoc-Davies added a comment -

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

Show
Ben Caradoc-Davies added a comment - See Nabble discussion: http://n2.nabble.com/Eclipse-integration-broken--td2631438.html
Hide
Permalink
Robert Newson added a comment -

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.

Show
Robert Newson added a comment - 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.
Hide
Permalink
Arnaud Heritier added a comment -

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)

Show
Arnaud Heritier added a comment - 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)
Hide
Permalink
Rustam Abdullaev added a comment -

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.

Show
Rustam Abdullaev added a comment - 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.
Hide
Permalink
Joe Freeman added a comment -

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

Show
Joe Freeman added a comment - 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
Hide
Permalink
Ben Caradoc-Davies added a comment -

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.

Show
Ben Caradoc-Davies added a comment - 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.
Hide
Permalink
Ben Caradoc-Davies added a comment -

Thanks, Barrie.

Show
Ben Caradoc-Davies added a comment - Thanks, Barrie.
Hide
Permalink
Robert Watkins added a comment -

Still not fixed for Version 2.8, I see...

Show
Robert Watkins added a comment - Still not fixed for Version 2.8, I see...
Hide
Permalink
fabrizio giustina added a comment -

I'll try to work at this for 2.9, given the number of comments and vote for this issue I think the best solution could be reverting to the old (pre 2.6) behaviour and adding a new optional property in order to switch to the result expected in MECLIPSE-442.
WDYT?

Show
fabrizio giustina added a comment - I'll try to work at this for 2.9, given the number of comments and vote for this issue I think the best solution could be reverting to the old (pre 2.6) behaviour and adding a new optional property in order to switch to the result expected in MECLIPSE-442. WDYT?
Hide
Permalink
Ben Caradoc-Davies added a comment -

Fabrizio, that sounds like a good solution.

Documentation for the optional property should include a warning about JRE behaviour, as noted in this issue (JRE classes always loaded before 3rd party jars).

Fixing this issue would be much appreciated.

Kind regards,
Ben.

Show
Ben Caradoc-Davies added a comment - Fabrizio, that sounds like a good solution. Documentation for the optional property should include a warning about JRE behaviour, as noted in this issue (JRE classes always loaded before 3rd party jars). Fixing this issue would be much appreciated. Kind regards, Ben.
Hide
Permalink
fabrizio giustina added a comment -

Fixed for 2.9 by reverting the behavior introduced in MECLIPSE-442 but adding a new property that let user switch to the container-last mode if really needed (mostly for compatibility for projects that were working due to MECLIPSE-442).
Thanks to anybody helped by reporting the problem and voting for this to be fixed.

Show
fabrizio giustina added a comment - Fixed for 2.9 by reverting the behavior introduced in MECLIPSE-442 but adding a new property that let user switch to the container-last mode if really needed (mostly for compatibility for projects that were working due to MECLIPSE-442). Thanks to anybody helped by reporting the problem and voting for this to be fixed.

People

Vote (16)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.