Rar dependencies cause failure to build project

I was able to reproduce the problem with m2eclipse 0.9.0

I tracked down the issue and found 2 possible solutions. But since I don't use rar files, I need help to choose the best one.

1. change plexus component configuration for rar files to disable their addition to classpath
see http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml

<component>
  <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
  <role-hint>rar</role-hint>
  <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
  <configuration>
    <type>rar</type>
    <language>java</language>
    <addedToClasspath>true</addedToClasspath> <--- change to false
  </configuration>
</component>

2. or add a test to m2eclipse code to avoid addition to dependencies when the file's extension is not .zip nor .jar

The first solution is the most clean, since it would be only a configuration improvement.
But I'm not able to decide if the changed configuration is right: should a .rar file be included in classpath or not?

I too would favour solution 1. And would treat .rar file in the same way .zip files are.

http://www.rarlab.com/rar_file.htm

Mauro, Herve, are you interested to contribute the patch and the test case for that?

I think that option 1 is problematic from the regular maven cli point of view. Because maven working in the ide and in command line will see different classpath. The issue is actually with JDT, which is using hardcoded list of extensions allowed in the buildpath for compilation. All in all, I think solution 2 makes bit more sense and we had it implemented, but probably lost it during refactoring (hence need to add a test this time).

Yes, I'm interested in contributing.

I just tried option 1, and didn't find any difference with cli: if addedToClasspath=false, the dependency is not added to classpath with Surefire. Then AFAIK, this option is totally consistent between m2Eclipse and mvn cli, which is not the case with option 2.
Did I miss something?

Mauro: the rar file in the test you provided is not a file compressed with rar tool, but it is Resource Adapter Archive, a J2EE notion http://maven.apache.org/plugins/maven-rar-plugin/ (and technically, it is a jar file with a different extension)
Wasn't it intentional?

The more I work on this issue, the more I'm convinced .rar files should be excluded from classpath by configuration in components.xml like .war files are
=> I should create a MNG issue then patch Maven core instead of m2eclipse

For other file extensions that are not explicitely configured in components.xml, I just made the test: they are not added to classpath with cli and don't create any problem in m2eclipse

solution 1 seems really the good one

WDYT?

in issue MRAR-17, proposed solution is to add the rar configuration in components.xml (which has been done since then (http://svn.apache.org/viewvc?view=rev&revision=593857)
but the configuration proposed at this time contained <addedToClasspath>false</addedToClasspath>

I think I'll work with this MRAR-17 issue to check if this configuration is really the good one

Herve, it seems like you are mixing rarlabs archive and rar bundle representing a resource adapter. For the latter it is actually legal to have classes in them and I'd say that Maven plugin currently does the right thing. So, we have to work around the JDT limitation and has hardcoded list of allowed archive extensions.

I read j2EE Connector Spec, and I'm now convinced that .rar files are exactly like war files: they should not be added to classpath (and they include their dependencies)
BTW, same issue with .ejb3 and .par files...

as soon as Maven 2.0.9 is released, I'll apply MNG-3497 change
Then there won't be any problem in m2eclipse with .rar files when embedder is updated

Herve, can you please do that in trunk, because that is the version used for dependency resolution.

I suppose you don't want to wait...
ok, done in trunk (and waiting 2.0.9 release to merge in 2.0.x branch)

I just checked and the problem is not here any more: embedder has been updated to version 2.1.0.20080413-2200, which contains MNG-3497 fix