FileSystemScanner does not populate groupid, breaks "In House" filter in Whitesource GUI

[justincranford]

Hello,

The Whitesource Admin GUI has filters to recognized jars as "In House". I want to use the groupid=com.mycompany* filter, but it only works for jars scanned by Maven fs-agent. It does not work for jars scanned with File System fs-agent scans.

Root cause is FileSystemScanner.java. It uses a hard-coded groupid=NULL value, so it never publishes the groupid, even though Maven embeds the pom.xml with that information in every jar by default. The information is there in the jars packaged by Maven, but FileSystemScanner.java calls the Coordinates() constructor like so:

       projectInfo.setCoordinates(new Coordinates(null, projectName, projectVersion))

To see what coordinates fs-agent sends to Whitesource GUI in different modes, I ran it in offline mode. I ran "mvn package whitesource:update" to do the fs-agent scan and jar packaging in a single run. The generated update-request.txt file sends these coordinates which can be uploaded manually into Whitesource Admin GUI.

       "coordinates": {
         "groupid": "com.mycompany.foo",
         "artifactId": "bar",
         "artifactId": "1.3.0",
       },

Now run fs-agent on the same jar with a File Systems scan. Even though Maven embedded the pom.xml at /META-INF/maven/groupid/artifactid/pom.xml by default, the fs-agent code does not publish the groupid in update-request.txt. The artifactid is a simple copy of the filename, and version inherits from projectVersion which comes from whitesource-fs-agent.config or a command line parameter.

       "coordinates": {
         "artifactId": "bar-1.3.0.jar",
       },

Fs-agent has Maven pom.xml parsing code, so it should be possible to reuse it to parse pom.xml during File System scans too. FileSystemScanner.java should be able to call the Coordinates() constructor similar to how MavenTreeDependencyCollector.java calls it like so:

 	projectInfo.setCoordinates(new Coordinates(tree.getGroupId(), tree.getArtifactId(), tree.getVersion()));

Please fix FileSystemScanner.java. If there is a pom.xml embedded in the jar, parse out the groupid, artifactid, and version. If pom.xml is not embedded, fall back on reporting NULL, filename, and projectVersion. Here is a sample snippet from a pom.xml file with a parent. The parent pom.xml is not required, because the child specifies the parent coordinates for dependency resolution.

 	<parent>
 		<groupId>com.mycompany</groupId>
 		<artifactId>parent</artifactId>
 		<version>1.3.0</version>
 	</parent>
 	<groupId>com.mycompany.foo</groupId>
 	<artifactId>bar</artifactId>

Sometimes other meta-data is only available from parent pom.xml. For example, values like copyright, license, SCM URL, and more are inherited from parent pom.xml. Since Maven only embeds the child pom.xml, and none of the parent pom.xml files, it would also be nice to make best effort to parse this extra info from child pom.xml if present. If the information if only present in parent pom.xml, skip this step, only make best effort for info in the child pom.xml files.

In summary, making these changes will improve the value of Whitesource reports. Any jars scanned by File System scanner, but packaged by Maven, should be reported with their Maven coordinates. Also, if fs-agent can scrap extra information directly out of the child pom.xml, that extra info can also be reported directly in the different Release reports and the Due Diligence report.

Thank you,
Justin Cranford