Sort out how to deal with "works with" dependencies

[waynebeaton]

"Works with" dependencies are a type of dependency that does not require full scrutiny of the IP Team. Often-times, these dependencies are not under open source licenses or are under incompatible licenses. Works with dependencies should not be directly distributed. They are, by definition, either optional or can be replaced with alternatives.

It is common, for example, to see them in a Maven dependency list.

The transitive closure of the dependencies of a works with dependency are themselves under the umbrella of the works with and so require no further scrutiny.

[waynebeaton]

The short answer/work around is that "works with" dependencies can be identified by the project team and filtered out of the content provided to the tool. With a Maven build, for example, you could ensure that all "works with" dependencies are in the "provided" scope and filter based on that. Or a project team could just maintain a file that lists all of the "works with" dependencies and use that to diff them out of a generated list.

"Works with" (and "build and test" by extension) are project-specific. It should, theoretically, be easy enough to provide a parameter to the tool that identifies the project to help with matching against that project. That will likely get us most of the way to a fully-automated implementation. Projects using content from another project that itself includes "works with" adds an extra challenge.

[sophokles73]

Putting works-with dependencies into Maven's provided scope might work in cases where the works-with dependency doesn't need to be included in the generated artifact, e.g. an über-jar or a Spring Boot executable jar. In systems that consist of multiple components that implement a service API and where you have multiple different implementations of the API, say a standard implementation and an optimized one, you will still want to provide the fully functional optimized artifact which includes the works-with dependencies. The optimized version will be an alternative to the standard component, hence being optional for the overall system. Having a dedicated list of the works-with dependencies seems to be a better option to me. Maybe we can also make use of Maven's optional marker for dependencies, but I'll need to take a deeper look into that.

[waynebeaton]

My first thought is that content that your project build puts into an über-jar would by definition by a "prerequisite". However, I can imagine scenarios where the über-jar is just one way in which the content may be packaged. Ideally that hypothetical content would be built optionally only when specifically requested. But just ignoring that hypothetical artifact is a reasonable workaround.

For readers who are not as familiar with our processes as Kai is, "works with" dependencies cannot be directly distributed by an Eclipse project. Having a build that produces artifacts that include "works with" is fine, but care needs to be taken to ensure that the consumer of the project's products is the one that acquires the "works with" content and agrees to the license terms. There's more in the handbook.

We might be able to do something with the mvn dependency:tree (or something even better with a plugin) to identify the root of a "works with" and ignore the transitive dependencies. In the general case, my sense is that we're going to end up with a collection of best practices for pruning the dependency list before sending it to the tool.

[waynebeaton]

For the Maven plugin, filtering out content before delivering it to the tool won't work.

Working from inside a Maven mojo does give us finer control over how we traverse the dependency tree, which means that if we can identify a "works with" dependency, we can just not descend the dependencies of that item.

A simpler option might be to just provide a means of feeding the tool an "ignore" list and encourage the project team to maintain that list of "works with" dependencies.

[waynebeaton]

The Maven plug-in has a feature to exclude various things. You can, for example, exclude groupids.

e.g.,

$ mvn org.eclipse.dash:license-tool-plugin:license-check -DexcludeGroupIds=org.openjdk.jmh

This only gets us part-way. It does not, for example, automatically chop off the dependencies of the ignored resources.