Michele Mostarda wrote:
> I would like to suggest you to do the same: mvn eclipse:eclipse [1] , you
> should obtain a self-consistent project ready to be opened with Eclipse.

Ciao Michele,
I have been experiencing problems as well using mvn eclipse:eclipse as you
suggested.

I simply checkout:
cd /tmp
svn co http://svn.apache.org/repos/asf/incubator/any23/trunk/ any23

Then:
cd any23
mvn eclipse:eclipse

I don't seem to remember having problems with Any23 a few weeks ago.

I think the Maven Eclipse plug-in does not work brilliantly when you
have resources which aren't within the project. I see this in some of
the Any23 pom.xml files:

    <resources>
      <resource>
        <directory>${basedir}/../../</directory>
        <targetPath>META-INF</targetPath>
        <includes>
          <include>DISCLAIMER.txt</include>
          <include>LICENSE.txt</include>
          <include>NOTICE.txt</include>
        </includes>
      </resource>
    </resources>

This causes the mvn eclipse:eclipse to put a wrong entry in the .classpath
Eclipse configuration file:

  <classpathentry kind="src" path="/tmp/any23"
including="DISCLAIMER.txt|LICENSE.txt|NOTICE.txt" excluding="**/*.java"/>

/tmp/any23 is the correct and absolute path, however Eclipse expect relative
paths as path="..." values or references to existing projects in your
workspace.

I see and understand why you want to have an additional <resource> and avoid
duplicating DISCLAIMER.txt, etc. in all the modules.

I do not have a solution, unfortunately.

The workaround for Eclipse users is to generate the Eclipse files as you
suggested via mvn eclipse:eclipse remove the offending <classpathentry
kind="src" path="..." ... /> entries from the .classpath files.
It can be a pain when dependencies change and someone needs to run
mvn eclipse:eclipse again.

Another alternative/workaround is copying/duplicating DISCLAIMER.txt, etc.
in all the modules and avoid <directory>${basedir}/../../</directory> with
../../ in it. Not ideal. But, those files do not often change and different
modules might need/want different content in their NOTICE.txt or at the
end of LICENSE.txt files.


By the way, another 'strange' thing I noticed with Any23 and Eclipse is
these three compilation errors in any23-core:

Method newInstance(Class<? extends Fix>) has the same erasure
newInstance(Class<T>) as another method in type DefaultValidator
DefaultValidator.java   /any23-core/src/main/java/org/apache/any23/validator
line 126        Java Problem
Method newInstance(Class<? extends Rule>) has the same erasure
newInstance(Class<T>) as another method in type DefaultValidator
DefaultValidator.java   /any23-core/src/main/java/org/apache/any23/validator
line 134        Java Problem
The method newInstance(Class<? extends Fix>) in the type DefaultValidator is not
applicable for the arguments (Class<capture#1-of ? extends Rule>)
DefaultValidator.java   /any23-core/src/main/java/org/apache/any23/validator
line 56 Java Problem

I do not see any error when I compile from the command line with Maven.
It might well be my quite old Eclipse version.

My 2 cents,
Paolo




Reply via email to