• Upgrade maven-plugin-plugin to 3.4
• Upgrade maven-invoker-plugin to 2.0.0 and cleaned up pom accordingly.
• Upgrade maven-source-plugin from 2.2.1 to 2.4 added config to replace
• configuration of the super pom to prevent forks of the life cycle.
• Upgrade doxia-module-markdown from 1.4 to 1.6
• Upgrade maven-shade-plugin from 2.3 to 2.4.1
• Upgrade maven-jar-plugin from 2.4 to 2.6
• Upgrade maven-assembly-plugin from 2.5.3 to 2.5.5
• Correct usage of maven-plugin-annotations (scope=provided)

This pull request contains some code cleanup and an important note in the documentation that the YAML scanner does not support all valid YAML documents.

Fix SONAR integration as in https://github.com/buschmais/jqassistant/issues/338 mentioned. Some more words:

• SONAR has had major changes in API since 3.7.4. These cannot be handled as compatible between the several api version. I increased also other plugin versions...
• The JavaResourceResolver still contains code possible not working, because the JavaFile replacement File, does not the same! Here we need more time to inspect. The JavaResourceResolverTest is currently @Ignore'd.
• I replaced also some other decpreactions by recommended alternatives.

Removed provider dependencies, cause this will be done by maven-surefire/maven-failsafe automatically. Added maven-enforcer rule to make sure maven-surefire/ maven-failsafe/maven-surefire-report-plugin will have the same version.

This pull request resolves #328. Unfortunately, it took some time because I was occupied.

The integration tests are not that nice because I used relations with some arbitrary properties to test that they are not interfering with the constraint. However, such properties cannot be used in programmatic relation descriptors as far as I know.

Some constraints allow ambigous relations with different line numbers: classpath:ResolveReads, classpath:ResolveWrites, classpath:ResolveInvokes, java:InvokesOverriddenMethod.

Hi,

here the promissed implementation of the Developers scanner extension. Unfortunately I couldn't just create a pull request for that single commit and hat do do it for some changes that should not be applied in the 1.1.3 version.

Chris

Hi Dirk, can you have a look at this. I changed the JarScannerPlugin so that it is creating a JarArchiveDescriptor for every jar file it scans. The name of the node matches the name of the scanned file. The contents of the jar file are added to the JarArchiveDescriptor node by a CONTAINS relation. There is a global variable in JarScannerPlugin. This only works if a JarScannerPlugin is not reused by different scans. I'm not seeing a way to avoid the global variable here. Btw. My formatting settings don't match yours. Could you make your settings available?

When I started with jqassistant, I worked with 1.0.0-M1​​. This version put the html reports in the same directory as the analysis (target/jqassistant). But after I changed to 1.0.0-M2-SNAPSHOT, there was no html report anymore. The log output of the plugin had also changed:

from

[INFO] Transforming C:\Users\nachtgold\jQAssistentTestProject\target\jqassistant\jqassistant-report.xml to C:\Users\nachtgold\jQAssistentTestProject\target\jqassistant\jqassistant-report.html.

to

[INFO] Transforming C:\Users\nachtgold\jQAssistentTestProject\target\jqassistant\jqassistant-report.xml.

So I thought the plugin is not ok and I created an integration test. After I started the test, I found the html report in the directory target/site :smile: So everything is fine, but maybe you are interested in my integration test.

Version 3.2.1 has a CVSS 10.0 vulnerability. That's the worst kind of vulnerability that exists. By merely existing on the classpath, this library causes the Java serialization parser for the entire JVM process to go from being a state machine to a turing machine. A turing machine with an exec() function!

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8103 https://commons.apache.org/proper/commons-collections/security-reports.html http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

When creating the MavenPomXmlDescriptor out of the org.apache.maven.model.Model then it should be respected that groupId and version can come from the parent (see code).

Version 3.2.1 has a CVSS 10.0 vulnerability. That's the worst kind of vulnerability that exists. By merely existing on the classpath, this library causes the Java serialization parser for the entire JVM process to go from being a state machine to a turing machine. A turing machine with an exec() function!

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8103 https://commons.apache.org/proper/commons-collections/security-reports.html http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/