add support for resolving jars' licenses#53
Conversation
|
Could you be clear in the PR comments? What is your resolving way? |
|
In fact, this is not one new implement. In the last pr, we searched for the license files that the maven project depends on from two places:
Now we separate jar file resolver from maven resolver to support that resolves a series of jar files entered by the user |
I just submitted a description |
|
We need a document to list the license resolving mechanism. Not just for Maven, for all supported language ecosystems. FYI @kezhenxu94 |
|
Let's create an issue to track this document requirements. |
kezhenxu94
left a comment
There was a problem hiding this comment.
This feature is for a scenario where users already have their distribution packages and check the final .jar files, the key point is that we need to expand all .jar files in the patter like:
dependency:
files:
- go.mod
- dist/**/*.jar| return nil, err | ||
| } | ||
|
|
||
| if _, err := exec.Command("mvn", "dependency:copy-dependencies", "-DoutputDirectory=./lib", "-DincludeScope=runtime").Output(); err != nil { |
There was a problem hiding this comment.
This is not portable, users / developers don't have mvn installed won't be able to run this test
There was a problem hiding this comment.
The purpose of this test is to check the usability of the JarResolver. Can I put the jar files directly in the test/testdata?
There was a problem hiding this comment.
The purpose of this test is to check the usability of the JarResolver. Can I put the jar files directly in the test/testdata?
you can put binary files (.jar) files in the codebase but we can't release them, this is unusual case, maybe we can only run this test case when mvn is available, otherwise we skip this test?
There was a problem hiding this comment.
you can put binary files (
.jar) files in the codebase but we can't release them, this is unusual case, maybe we can only run this test case whenmvnis available, otherwise we skip this test?
ok, i will check the availability of mvn first
|
|
||
| func (resolver *JarResolver) Resolve(jarFile string, report *Report) error { | ||
| state := NotFound | ||
| if err := resolver.ResolveJar(&state, jarFile, report); err != nil { |
There was a problem hiding this comment.
In this resolver (jar resolver), we should support a path pattern like dist/**/*.jar and expand all the .jar files and resolve their licenses, the current feature in this PR only support a singe .jar file, right?
There was a problem hiding this comment.
From my understanding, JarResolver is only responsible for resolve the licenses of jar files. And deps/config.go will enter all jar files in the dist/**/*.jar
There was a problem hiding this comment.
From my understanding, JarResolver is only responsible for resolve the licenses of jar files. And
deps/config.gowill enter all jar files in thedist/**/*.jar
Well, now, it seems deps/config.go doesn't expand the pattern dist/**/*.jar to all .jar files (like dist/module1/log4j.jar, dist/module2/junit.jar), we should do this, right?
There was a problem hiding this comment.
Well, now, it seems
deps/config.godoesn't expand the patterndist/**/*.jarto all.jarfiles (likedist/module1/log4j.jar,dist/module2/junit.jar), we should do this, right?
Yes, it will be complete in the next pr
There was a problem hiding this comment.
Well, now, it seems
deps/config.godoesn't expand the patterndist/**/*.jarto all.jarfiles (likedist/module1/log4j.jar,dist/module2/junit.jar), we should do this, right?Yes, it will be complete in the next pr
Nice
|
How far are we from using this in main repo and the next release? |
For now this feature is only helpful to assist human to audit the licenses, the key to make it available in main repo (automatically report conflict licenses and fail the CI) is to provide a license compatibility matrix and check the final resolved licenses. We might provide another command |
No description provided.