#1111 [patch] FindBugs plugin breaks for "Resolve in workspace"

3.0.0
closed-fixed
3
2014-06-21
2012-08-21
Derek
No

The newer version of IvyDE support a feature called "Resolve in workspace":
http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/workspace.html

Previously, dependencies of a project in Eclipse would come in via two paths:
- third party jars were imported via Ivy (an ivy.xml file)
- project dependencies were explicitly specified in Eclipse as dependent projects

With the new version of IvyDE, it became possible to encode the dependencies entirely via Ivy. This means that the special Ivy classpath container in Eclipse now contains not only jars but also the dependent projects.

In testing, FindBugs didn't seem to like this setup very much. All of the classes in the dependent projects could no longer be found after we made this change to our setup (we got a lot of class missing for analysis errors).

This isn't a huge problem for us - we'll just keep configuring our dependencies the old way. I just wanted to mention this because there seems to be some dependency in how the classpath is used in the FIndBugs Eclipse plugin that is not compatible with this newish feature of IvyDE.

Discussion

  • Derek

    Derek - 2012-09-13

    Yeah, that's totally fair: we are also considering migrating off of IvyDE (and using Maven). I'll send a patch if we do end up looking into this.

     
  • William Pugh

    William Pugh - 2012-11-15
    • priority: 5 --> 3
    • status: open --> open-postponed
     
  • Derek

    Derek - 2013-03-02

    Ok, i dug into this more and the bug is in PDEClassPathGenerator. The issue seems to be that IvyDE creates a special ClasspathEntry which is a reference to a project instead of a directory. This entry returns a path that looks like this:
    /ProjectName/
    which is then rejected by the isValidPath check.

    Since this check seems to be for a weird bug in older versions of Eclipse, I tried to code up a fix that is as conservative as possible (by keeping the rejection logic) but recovers by checking if the entry is of type project and then handles it.

    So this code would go in PDEClassPathGenerator around line 101:
    if (isValidPath(path)) {
    classPath.add(path.toOSString());
    } else if (iClasspathEntry.getEntryKind() == IClasspathEntry.CPE_PROJECT) {
    Project project = (Project) JavaModel.getTarget(path, true);
    IProject project2 = project.getProject();
    String[] otherClassPath = JavaRuntime.computeDefaultRuntimeClassPath(javaProject);
    for (String classpathEntry : otherClassPath) {
    IPath path2 = new Path(classpathEntry);
    if (isValidPath(path2)) {
    System.out.println(path2);
    classPath.add(path2.toOSString());
    }
    }
    }

    This code basically imitates what is done earlier in the method, so it could be easily pulled out into a helper method, but I kept it inline here for brevity.

    This may not be the most elegant fix (I noticed that some of these things produce discouraged access warnings), but it works and should be a good starting point for someone more familiar with the Eclipse APIs. Please let me know if I can provide any additional assistance on getting this fixed.

     
  • Andrey Loskutov

    Andrey Loskutov - 2014-06-21
    • labels: Eclipse plugin --> Eclipse plugin, patch
    • summary: FindBugs plugin breaks for "Resolve in workspace" --> [patch] FindBugs plugin breaks for "Resolve in workspace"
    • status: open-postponed --> open-accepted
    • Group: --> 3.0.0
     
  • Andrey Loskutov

    Andrey Loskutov - 2014-06-21
    • status: open-accepted --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks