Configure package exclusions?

[tayloj]

The README.md mentions that (emphasis added), "[the] plugin executes the Jdepend library (packaged within the plugin) during the execution of the SonarQube scanner to scan the binaries, so no extra configuration is needed within the project."

However, there are some configuration options that would be nice to set. JDepend supports jdepend.properties file that can be used to specify packages to ignore during analysis. The Eclipse JDepend plugin provides similar functionality in preferences. Without being able to do exclude some packages from analysis, the Sonar plugin, many of the measures seem artificially high.

For instance, I have one package which, without disabling any "library" packages, has an instability of 0.93. When I disable java.*, javax.*, org.apache.*, and org.slf4j.*, it's down to 0.50, which is probably more realistic, since those dependencies aren't really likely to change.

Can the package settings be configured somehow for the plugin? It'd be nice to have to change the thresholds for the rules, or to have ignore a bunch of issues if the configuration could be changed slightly.

[willemsrb]

Hi Joshua (@tayloj),

Thanks for your message.

I think something could be done with the jdepend.properties. Could you try to put the jdepend.properties in the directory configured by the system environment variable 'user.home'?

JDepend seems to work by default on this file:

    public static File getDefaultPropertyFile() {
        String home = System.getProperty("user.home");
        return new File(home, "jdepend.properties");
    }

If need be i could try to work around the JDepend constructor to have the plugin read the jdepend.properties file from the project root currently being processed.

Regards, Robert

[willemsrb]

I don't understand the second part of the issue:

Can the package settings be configured somehow for the plugin? It'd be nice to have to change the thresholds for the rules, or to have ignore a bunch of issues if the configuration could be changed slightly.

Could you elaborate on what exactly you would like to configure on which level?

[tayloj]

@willemsrb Honestly, I'm not sure exactly what I meant there. Maybe I hadn't had enough coffee when I posted. I think that I was thinking of the severity of the issues in Sonar, and the "maximum allowed" type settings, but those are obviously configurable in Sonar already (as shown below). I'll edit the comment and remove that part, since it doesn't really make sense.

[tayloj]

So, seeing that JDepends will look in user.home for a jdepends.properties file got me looking into PropertyConfigurator.java, and it turns out that if there isn't a properties file in user.home, JDepends will look for one in the root of the classpath.

If classpath resources from the analyzed code are available, then that would be one option to get JDepends to pick them up. If they're not, maybe there's a way to make it available to the Sonar plugin. I'll keep digging on this.

Relevant code includes:

    public static File getDefaultPropertyFile() {
        String home = System.getProperty("user.home");
        return new File(home, DEFAULT_PROPERTY_FILE);
    }

    public static Properties loadProperties(File file) {
        Properties p = new Properties();
        InputStream is = null;
        try {
            is = new FileInputStream(file);
        } catch (Exception e) {
            is = PropertyConfigurator.class.getResourceAsStream("/"
                    + DEFAULT_PROPERTY_FILE);
        }

[willemsrb]

Ok, great. Please let me know if that works. If so, I can update the documentation, otherwise I will read the configuration from a file and configure the Jdepend class with it.

[willemsrb]

I also need coffee :), didn't read your comment properly.

During the execution of the plugin, as far as i know, the code to be analysed is not available on the classpath. I can however load a jdepend.properties from the project directory and use that to load the PropertyConfigurator of Jdepend; pass the filters to constructor of the JDepend class; and reconfigure the JDepend class after the constructor loads the default settings (cannot pass the configurator directly to the constructor..).

I'm out of town a few days; i'll update the plugin at the end of the week when i'm back.

[tayloj]

During the execution of the plugin, as far as i know, the code to be analysed is not available on the classpath. I can however load a jdepend.properties from the project directory

I'm not sure how I feel about that idea; should a plugin do something non-trivial with the content of a project like that? Maybe it's fine, I'm not a Sonar plugin developer.

Is there an easy way to just add one more file to the classpath that's active when the plugin is running? I know that the plugins have access to system properties defined with -D on the maven command line. E.g, things like

mvn sonar:sonar -Duser.home=...

work, and could be used to specify a location for jdepend.propeties. The problem that though is that user.home is also where ~/.m2 is supposed to go, so we end pulling the dependencies into the project directory, which is no good.

Is there a command line switch to just add one more thing to the classpath, e.g.:

mvn sonar:sonar -extraClassPathResource=jdepend.properties

That would solve the problem as far as I'm concerned.

[willemsrb]

I think we are moving to the same goal, but are describing it differently.

I'm definately not ok with a tool requiring a change in the 'result' of a project. So i won't change or read anything from the classpath of the project to be analyzed. However having a configuration file within the project structure (next to the pom.xml for a maven project) is something that would not change the 'result' (eg anything in the /target/) of a project. It would however allow a configuration for jdepend for each project.

I've added a little code that can read a jdepend.properties file from the project directory and configure jdepend accordingly. If the file does not exist it will fallback to the default jdepend configuration.

[willemsrb]

Could you check if this is sufficient for your use case? If so, i'll make a release candidate in the beginning of next week, so it can be released next week.