AEM Rules plugin 0.8 is not compatible with SonarJava 4.10

[Julien Lancelot]

Hi,

The latest release of the AEM Rules plugin (version 0.8) is not compatible with the latest version of the SonarJava plugin (version 4.10).

Indeed, SonarJava has updated the way Guava is used : Guava is now minimized, only classes that are used are bundled.

As the AEM Rules plugin is based on the Java plugin and is using Guava through transitive dependency, it's no more possible to use this plugin.

To the maintainers of the plugin, here is how to fix this issue : 

• Remove the fact that this plugin is based on the Java plugin by removing <requirePlugins> and <basePlugin> lines from the pom.xml
• Add Guava as dependency
  

Regards,

--

Julien Lancelot | SonarSource

http://sonarsource.com

[michal...@cognifide.com]

Hi Julien,

thanks for this piece of advice. It's a shame I only noticed this post now. :-) What's interesting, I wasn't able to download 4.10 jar from maven central until today.

Here's new release candidate that works with 4.10:

https://groups.google.com/forum/#!searchin/sonarqube/aem%7Csort:relevance/sonarqube/JxTVzD-wUmU/cTRGIKCiBwAJ

I've already embedded guava into the plugin, however I did not removed the dependency on Sonar Java plugin, because I actually use lots of it's classes. So I can not remove maven dependency from it and therefore I don't see a point in removing <requirePlugins> and <basePlugin>, because my plugin simply wouldn't work without it. Or am I missing something?

Many thanks for caring and trying to contact me! Please use GitHub channel next time. :-)

[Julien Lancelot]

Hi Michal,

It's a good news that you're about to release a compatible version of the plugin with SonarQube 6.4.

About the removal of the dependency with SonarJava, in fact I was probably not clear enough. The usage of  <requirePlugins> and <basePlugin> allow you to have access to the classloader of the Java plugin and to use internal classes.

But from what I saw in the AEM rules rules plugin, you're only using classes from the Java API, which can be easily done with a maven dependency, and then you won't need anymore the <requirePlugins> and <basePlugin>.

Regards,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5b1277eb-9612-4f45-9616-1f6ed600ea35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[michal...@cognifide.com]

Hi Julien,

would you be so kind to help me with this topic? I want to make sure I understand everything clearly.

For now, I'm using following classes and packages in my plugin that come from the Java plugin:

org.sonar.plugins.java.api.*

org.sonar.java.matcher.MethodMatcher

org.sonar.java.matcher.TypeCriteria

org.sonar.java.ast.parser.ArgumentListTreeImpl;

The first one is quite obvious that it's coming from API, however can you confirm that the latter ones are as well always provided to the every plugin's class loader?

I'm still using following dependency, which contains the API classes as well. I was trying to find more of an API-only dependency, but I guess there's nothing like that around. I was trying to completely break the dependence and I've made quite a leap making sure that I will not rely on any transitive dependencies.

https://github.com/Cognifide/AEM-Rules-for-SonarQube/pull/71

<dependency>
    <groupId>org.sonarsource.java</groupId>
    <artifactId>sonar-java-plugin</artifactId>
    <version>4.10.0.10260</version>
    <scope>provided</scope>

    <exclusions>
        <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

However, at the end of the day my plugin still does not work without Java plugin being installed on SonarQube.

And I get following stacktrace:

Caused by: java.lang.NoClassDefFoundError: org/sonar/plugins/java/api/CheckRegistrar
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.access$100(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at org.sonar.classloader.ClassRealm.loadClassFromSelf(ClassRealm.java:125)
	at org.sonar.classloader.ParentFirstStrategy.loadClass(ParentFirstStrategy.java:37)
	at org.sonar.classloader.ClassRealm.loadClass(ClassRealm.java:87)
	at org.sonar.classloader.ClassRealm.loadClass(ClassRealm.java:76)
	at com.cognifide.aemrules.AemRulesSonarPlugin.define(AemRulesSonarPlugin.java:31)
	at org.sonar.server.plugins.ServerExtensionInstaller.installExtensions(ServerExtensionInstaller.java:63)
	... 9 common frames omitted

Which makes me think that I should not remove the manifest dependency, since I will always actually depend on Java plugin after all. 

I'm not however sure how the classes, which I import as a part of my plugin like Guava classes or StringUtils will interfere with the Java plugin itself.

What do you think?

Kind regards,

Michał

[Julien Lancelot]

Hi Michal,

If you really need : 

org.sonar.java.matcher.MethodMatcher

org.sonar.java.matcher.TypeCriteria

org.sonar.java.ast.parser.ArgumentListTreeImpl;

It won't be possible indeed to not depend on the Java plugin.

I think you should consider to not use these packages, but I don't know even the Java plugin to help you to not depend on them.

I will let other people having more knowledge on it answer you !

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/48e651ea-06ba-4172-bcc8-e18f579ec229%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Gumowski]

Hey Michał,

Let me try to answer your question from a SonarJava plugin perspective.

The following classes are definitely not part of the API but only used internally:

org.sonar.java.matcher.MethodMatcher

org.sonar.java.matcher.TypeCriteria

org.sonar.java.ast.parser.ArgumentListTreeImpl;

Consequently, I don't see how you could not depend of the plugin. 

We have been developing the MethodMatcher and TypeCriteria classes for a while now, and it could be a nice idea to move them to API at some point. I know how useful they can be. I created the following ticket to handle it: SONARJAVA-2357). The ArgumentListTreeImpl is however purely internal and should definitely not be used in any custom rules. What do you need from it which is not exposed in the org.sonar.plugins.java.api.tree.Arguments API !? I can't see anything from the implementation class which is not already exposed.

This is also the Java Plugin which handle registration of custom rules. You need the CheckRegistrar to register them, and that's the JavaPlugin which trigger the rules.

Regarding Guava and StringUtils dependencies, I'm unfortunately far to be an expert in class loading, so I would only encourage you to try using your own versions, and see how it works. Maybe try using methods from Guava which are typically not present in the version used by SonarJava.

Hope this helps,

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CADxMB_NH9OpKvxWojn1-dU1muHhPR_E%3DLiNxMBChpAxs-rspjA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
http://sonarsource.com

[michal...@cognifide.com]

Hi Michael,

thanks for response,

So even if I get rid off these three classes, even by copying them into my plugin, I will still need to have dependency to CheckRegistrar. 

Therefore, I think that actually I should keep this dependency to Java Plugin. What about classes like org.sonar.plugins.java.api.tree.MethodTree? Are they provided by Java Plugin as well?

Br,

Michał

[Michael Gumowski]

Hey,

Everything which is under packages  "org.sonar.plugins.java.api. ..." or  "org.sonar.java.ast.api. ..." is provided by the SonarJava plugin, and should be considered as API. It includes all the Tree interfaces from the syntax tree, which is the result of the SonarJava parsing. So to answer your question, yep, the MethodTree is provided by the SonarJava plugin.

Regards,

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/999ee498-1153-45a7-94ab-dbc5e2439c66%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.