#410 Custom checks XML not loaded if plug-in does not use bundle shape dir

[Eric Milles]

I have been experimenting with loading our shared Checkstyle checks to a custom profile as a plug-in so that I don't need to keep copying XML all over out projects. I followed the plug-in extension directions and modeled after the example. The trouble that I have run into is that I don't think the current Checkstyle plug-ins support loading custom reulsets unless the extension plug-in is deployed as a directory (Eclipse-BundleShape: dir).

This is my plugin.xml:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
  <extension point="net.sf.eclipsecs.core.checkstyleAddonProvider" />
  <extension point="net.sf.eclipsecs.core.configurations" id="our.eclipse.checkstyle.checks">
    <check-configuration location="cobalt_checks.xml" default-weight="11"
      name="%checks.cobalt.name" description="%checks.cobalt.description"
    />
  </extension>
</plugin>

And the cobalt_checks.xml is at the root of the src tree.

When deployed as a jar (default for PDE), Eclipse sees the custom ruleset and lists it in the Window > Preferences > Checkstyle > Global Check Configurations list. However, selecting it and clicking Configure... goes nowehere. If I deploy my plug-in as a directory, all is well, so I know the project is setup okay.

Also, I looked at the net.sf.eclipsecs.core and net.sf.eclipsecs.checkstyle plug-ins to see how the other global checks are deployed. They are a bit misleading because the core plug-in lists the 3 built-in global checks in its plug-in xml, but I think the expanded checkstyle plug-in with its nested checkstyle-X-all.jar is where those XMLs are loaded from for config. That is, if net.sf.eclipsecs.checkstyle was deployed as a jar, I think the 3 built-ins would exhibit this same issue.

[Eric Milles]

I just remembered some details about why this does not work. When providing a built-in configuration in the default package (root of plug-in jar), there is no way for the plug-in to export that package. Therefore OSGi fails the request for the resource. The net.sf.eclipsecs.checkstyle exports the checkstyle-X-all.jar, which contains the usual 3 built-in checks at the root of the inner jar. In this case, OSGi can find the XMLs in the default package. A plug-in deployed as a dir may be able to export the default package, but I haven't been able to test this, since PDE does not deploy this way when debugging, so it is inconvenient to work this way.

So, at a minimum, a note should be made in the extension point docs (and/or wiki) and in the example plug-in that a new built-in check location must be something that is exported from the bundle.

[Lars Koedderitzsch]

I just retested this on the 7.1 branch, where I switched packaging of net.sf.eclipsecs.checkstyle to jar'ed form.
Test subject was the net.sf.eclipsecs.sample plugin also deployed as a jar. This sample plugin also contains the Checkstyle configuration file in the root folder.
This worked.

Then I tested just deploying the sample plugin via a PDE runtime workspace (extension developer scenario).
This worked as well.

I would appear that there is a subtle difference in your setup compared to the sample project. Please recheck plugin.xml and Manifest.MF. Also checking build.properties might be worth a shot, as the cobalt_checks.xml might just not be packaged.

[Eric Milles]

Thanks for checking. For your sample built-in config, did you click Configure...? That is where I have a problem. I can get the check to show up in the list of built-ins. I have it at the root of the src folder, which is included by build.properties. I can confirm this from the exported jar as well.

Here is the top of the stacktrace when I double-click on my new built-in config in the prefs dialog.

java.lang.NullPointerException
at net.sf.eclipsecs.core.config.configtypes.ConfigurationType.getCheckstyleConfiguration(ConfigurationType.java:147)
at net.sf.eclipsecs.core.config.CheckConfigurationWorkingCopy.getCheckstyleConfiguration(CheckConfigurationWorkingCopy.java:358)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor.configureCheckConfig(CheckConfigurationWorkingSetEditor.java:500)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor.access$6(CheckConfigurationWorkingSetEditor.java:492)
at net.sf.eclipsecs.ui.config.CheckConfigurationWorkingSetEditor$PageController.widgetSelected(CheckConfigurationWorkingSetEditor.java:391)

Sample build.properties: https://sourceforge.net/p/eclipse-cs/git/ci/master/tree/net.sf.eclipsecs.sample/build.properties
My build.properties:

source.. = src/
output.. = bin/
bin.includes = .,\
               META-INF/,\
               OSGI-INF/,\
               plugin.xml

Sample plugin.xml: https://sourceforge.net/p/eclipse-cs/git/ci/master/tree/net.sf.eclipsecs.sample/plugin.xml
My plugin.xml:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
  <extension point="net.sf.eclipsecs.core.checkstyleAddonProvider" />
  <extension point="net.sf.eclipsecs.core.configurations" id="our.eclipse.checkstyle.checks">
    <check-configuration location="cobalt_checks.xml" default-weight="11"
      name="%checks.cobalt.name" description="%checks.cobalt.description"
    />
  </extension>
</plugin>

Sample manifest: https://sourceforge.net/p/eclipse-cs/git/ci/master/tree/net.sf.eclipsecs.sample/META-INF/MANIFEST.MF
My manifest:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-Name: %bundle.name
Bundle-Version: 1.0.0.qualifier
Bundle-SymbolicName: our.eclipse.checkstyle.checks;singleton:=true
Bundle-Localization: OSGI-INF/bundle
Require-Bundle: org.eclipse.ui.ide,
 net.sf.eclipsecs.ui;bundle-version="[5.6.0,7.0.0)",
 net.sf.eclipsecs.core;bundle-version="[5.6.0,7.0.0)"
Export-Package: our.eclipse.checkstyle.checks

[Lars Koedderitzsch]

Please try dropping the Export-Package directive in your MANIFEST.MF. It's likely not required unless you want to have further plugins depending on your plugin.

[Eric Milles]

I tried removing Export-Package and even adding net.sf.eclipsecs.checkstyle to the Require-Bundle and no joy. I must admit my PDE dev env uses Juno and EclipseCS 6.11 to ensure best compatibility for our devs. I'll have to get 6.19 setup and see if there is any difference.

[Lars Koedderitzsch]

I don't know about Juno anymore but I have a working setup at work with an extension plugin providing a custom configuration which works for Kepler/Luna/Mars.

Require-Bundle for net.sf.eclipsecs.checkstyle is only required if your extension provides custom Checkstyle checks.
Anyway if you want you can send me your extension project via private mail and I'll have a look at it.

[Eric Milles]

I loaded the sample plug-in into my Juno PDE and it does work as you confirmed. I'll poke around and see if I can figure out what particular setting is causing me grief.

Note 1: My exported plug-in works fine (as a jar) with built-in checks at root of src. Only the local PDE deployment is failing.

Note 2: When I move the built-in checks to the root of the project (as mentioned on http://eclipse-cs.sourceforge.net/#!/builtin-config) and add a reference in build.properties, it works as it does for the sample. Could you add a note that the file must be included in the build.properties on that guide?

I'll see if I can find what is causing PDE to miss the resource or treat it differently. It seems it should work with a built-in config XML at the root of src because it gets copied to bin as a resource and that dir should be deployed as-is.

Note 3: I changed the location of the config xml (in plugin.xml) to "bin/cobalt_checks.xml" and it loads successfully. It would seem the PDE exporter is not placing resources in the right spot in the exported plug-in when using the Eclipse Application run configuration. Not sure if I can remap this or not. This bug seems to discuss the same issue and goes into quite a lot of detail: https://bugs.eclipse.org/bugs/show_bug.cgi?id=153023

[Eric Milles]

One change I could offer is in BuiltinConfigurationType. Loading the file as a classpath resource should pick up on Eclipse's additions to the classpath for a bundle run out of the IDE. FileLocator.find is only looking from the root of the plug-in project and so it misses any files that come from source directories.

public class BuiltInConfigurationType extends ConfigurationType {
    protected URL resolveLocation(ICheckConfiguration checkConfiguration) {

        String contributorName = checkConfiguration.getAdditionalData().get(CONTRIBUTOR_KEY);

        Bundle contributor = Platform.getBundle(contributorName);
        URL locationUrl = FileLocator.find(contributor, new Path(checkConfiguration.getLocation()), null);

        // new condition:
        if (locationUrl == null) {
            locationUrl = contributor.getResource(checkConfiguration.getLocation());
        }

        return locationUrl;
    }

[Lars Koedderitzsch]

I've added the suggested fallback to contributor classpath resolution for builtin configurations.