Thanks for the fix. Unfortunately I'm tempted in reopening the bug (once I figure how to do it
)
The fix is actually not working properly if the jar itself isn't located in the mavenrepo.
Let's take an example that part of our build scheme:
In the build.properties we defines the following (variable defined in maven script loader):
maven.jar.tools = $
{tools.jar}
Then in the project.xml we defined the dependency:
<dependency>
<id>tools</id>
</dependency>
This unfortunately ends up being wrong in the final .classpath generated by the eclipse plugin.
Here is the patch we're using for the moment until a final solution is found for those overriden jar that doesn't exist in the maven repository.
Index: classpath.jelly
===================================================================
RCS file: /home/cvspublic/maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly,v
retrieving revision 1.21
diff -u -r1.21 classpath.jelly
— classpath.jelly 24 Sep 2004 15:51:01 -0000 1.21
+++ classpath.jelly 24 Sep 2004 17:58:02 -0000
@@ -145,6 +145,10 @@
<j:when test="$
{lib.dependency.groupId == 'cactus' and ignoreCactus}
">
<!-- ignoring junit dependency as we've already created it -->
</j:when>
+ <j:when test="$
{lib.dependency.id == 'tools:tools'}
">
+ <!-- add tools.jar specified from maven tools.jar location -->
+ <classpathentry kind="lib" path="$
{lib.path}
"/>
+ </j:when>
<j:otherwise>
<!-- make sure it's a classpath dependency -->
<j:set var="isClasspath" value="$
{lib.dependency.isAddedToClasspath()}
"/>
I added a unit test to verify that jar overrides work.. Check it out, and reopen if you disagree.. A unit test demontrating what you mean would be good.