-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add feature: support resolving pom.xml for maven #50
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question, this PR is only including dependency resolving, but not checking the dependencies license compatible, right?
All the dependencies licenses resolvers including Go, NPM don’t check license compatibility now, they just resolve the licenses for human’s reference. Checking license compatibility is out of the scope of this PR and will be discussed after the main resolvers (Java, NodeJS, Golang) can correctly resolve the licenses first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and #48 should be very similar PR, but why do the changes have so many differences?
Resolvers
is not changed here..licensserc.yaml
is not changed in Add support for resolving npm dependencies' licenses #48
pkg/deps/maven.go
Outdated
var err error | ||
_, err = exec.Command("mvn", "--version").Output() | ||
if err != nil { | ||
return | ||
} | ||
|
||
Resolvers = append(Resolvers, new(MavenPomResolver)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is not a good condition to check whether we should add the resolver:
mvn version
is not enough to determine whether maven resolver can be use, maven wrapper is also widely used in some projects.- We should log some warning / error logs when users' environment don't have maven installed, instead of failing silently.
My suggestion is
- just add the resolver to
skywalking-eyes/pkg/deps/resolve.go
Lines 29 to 32 in d6e232b
var Resolvers = []Resolver{ new(GoModResolver), new(NpmResolver), } - check whether
mvnw
exists in the same directory aspom.xml
first, if yes, usemvnw
, otherwise, usemvn
- run the needed command (
mvn copy-dependencies
), if it failed, we also fail the command and print some logs
pkg/deps/maven.go
Outdated
err := CheckMVN() | ||
if err != nil { | ||
logger.Log.Errorln("an error occurred when checking maven tool:", err) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's invoke this in maven resolver manually instead of in init
method, so that when users don't need to resolve pom.xml
files won't see these logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have moved it~
pkg/deps/maven.go
Outdated
err := resolver.CheckMVN() | ||
if err != nil { | ||
logger.Log.Errorln("an error occurred when checking maven tool:", err) | ||
return false | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please bear in mind, CanResolve
will be invoked for every kind of projects, not just maven projects, so if I just want to resolve Go project or NPM project, this error logs look weird to me. Note that I'm not saying we should not log this error, instead, we should only check mvn
right before when we need to run mvn
command, (in the Resolve
method), CanResolve
is only used to filter the resolver according to the files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get it~
pkg/deps/maven.go
Outdated
if err := os.Chdir(dir); err != nil { | ||
logger.Log.Errorf("an error occurred when entering dir <%s> to parser file <%s>:%v\n", dir, base, err) | ||
return false | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this part should be moved into CheckMVN
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok~
pkg/deps/maven.go
Outdated
_, err = exec.Command("./mvnw", "--version").Output() | ||
if err == nil { | ||
resolver.maven = "./mvnw" | ||
logger.Log.Debugln("use mvnw") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mvnw is found, will use mvnw by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean to modify the log message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean to modify the log message?
Uh yes, sorry, didn't make it clear 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is my fault, I didn't understand it well😅
added some patterns describing the possible locations of license, but does not work for some jar packages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should i crawl the original webpage or judge directly from the url to identify the license
We can consider this later, we don't need to do all in one PR (which is hard to review and cost too long to finish), we can deliver minimal yet complete features step by step, in this PR I think it's OK to only support the "standard" dependencies that have a |
ok~, i will do it |
pkg/deps/maven.go
Outdated
return fmt.Errorf("neither found mvnw nor mvn") | ||
} | ||
|
||
logger.Log.Debugln("mvnw is not found, will use mvn by default") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not needed / correct now,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i have removed it
pkg/deps/maven.go
Outdated
} | ||
|
||
func (resolver *MavenPomResolver) DownloadDeps() error { | ||
cmd := exec.Command(resolver.maven, "process-resources") // #nosec G204 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be problematic in multi-modules maven project, can you try this feature in our main repo http://github.com/apache/skywalking ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as you said in discussion, the failure may be caused by submodules. so i resolve it using maven command install -DskipTests
to install possible need dependencies, and it may take some time.
Just a reminder, I am not sure whether this could be fixed easily. Maven includes a plugin called |
thanks for your help, and i am using |
My point is, the module using this plugin, may escape from your dependency check. You should check the case. |
sorry, I didn’t understand it very well. does this mean giving up on resolving these module? since the shaded package will be packaged during the |
I don't know. This is only a reminder, I just recommend you to check. |
ok, I've got the information. i will attemp it later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! This is closing to serve as the 1st version for maven projects, though we may have some corner cases to consider later. 👍🏻
I left some comments, please take a look
pkg/license/identifier.go
Outdated
var seemLicense = regexp.MustCompile(`(?i)licen[sc]e|copyright|copying`) | ||
|
||
// Seem determine whether the content of the file may be a license file | ||
func Seem(content string) bool { | ||
return seemLicense.MatchString(content) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you reuse possibleLicenseFileName
in file golang.go
? it may not be a good idea to put possibleLicenseFileName
in identifier.go
but now let's unify the 2 places, you can move possibleLicenseFileName
into identifier.go
later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you reuse
possibleLicenseFileName
in filegolang.go
? it may not be a good idea to putpossibleLicenseFileName
inidentifier.go
but now let's unify the 2 places, you can movepossibleLicenseFileName
intoidentifier.go
later.
the purpose of Seem
function was to simply determine whether one file may be a license base on the input content, not the file name. i remove it from identifier.go
now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @MoGuGuai-hzr for the great work and patience 🙇🏻
Solution: copy, using
mvn dependency:copy-dependencies
, all dependencies and transitive dependencies, and then resolve license from the jar files.Known disadvantages: