-
Notifications
You must be signed in to change notification settings - Fork 308
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
Scanning projects should not claim the same file for different projects (of the same type) #5365
Labels
Comments
sschuberth
added
enhancement
Issues that are considered to be enhancements
scanner
About the scanner tool
labels
May 20, 2022
This was referenced May 20, 2022
And as mentioned by @mnonnenmacher over here, in the context of this it should also be ensured that Unmanaged project only get the "left-overs" associated that cannot be accosicated to any other project according to the logic. |
bennati
added a commit
to bennati/ort
that referenced
this issue
May 23, 2022
Local directories that are dependencies can appear in the analyzer results both as packages, e.g. Pub, and projects. After building the results, projects are removed if they match with packages on VCS information and package manager type. This is caused by issue oss-review-toolkit#5365. This is only a workaround which should be replaced by a comprehensive solution for oss-review-toolkit#5365.
bennati
added a commit
to bennati/ort
that referenced
this issue
May 23, 2022
Local directories that are dependencies can appear in the analyzer results both as packages, e.g. Pub, and projects. After building the results, projects are removed if they match with packages on VCS information and package manager type. This is caused by issue oss-review-toolkit#5365. This is only a workaround which should be replaced by a comprehensive solution for oss-review-toolkit#5365.
sschuberth
changed the title
Scanning packages should not claim the same file for different packages (of the same type)
Scanning projects should not claim the same file for different projects (of the same type)
May 24, 2022
bennati
added a commit
to bennati/ort
that referenced
this issue
Jun 17, 2022
Local directories that are dependencies can appear in the analyzer results both as packages, e.g. Pub, and projects. After building the results, projects are removed if they match with packages on VCS information and package manager type. This is caused by issue oss-review-toolkit#5365. This is only a workaround which should be replaced by a comprehensive solution for oss-review-toolkit#5365.
bennati
added a commit
to bennati/ort
that referenced
this issue
Jun 17, 2022
Local directories that are dependencies can appear in the analyzer results both as packages, e.g. Pub, and projects. After building the results, projects are removed if they match with packages on VCS information and package manager type. This is caused by issue oss-review-toolkit#5365. This is only a workaround which should be replaced by a comprehensive solution for oss-review-toolkit#5365.
bennati
added a commit
to bennati/ort
that referenced
this issue
Jul 6, 2022
Local directories that are dependencies can appear in the analyzer results both as packages, e.g. Pub, and projects. After building the results, projects are removed if they match with packages on VCS information and package manager type. This is caused by issue oss-review-toolkit#5365. This is only a workaround which should be replaced by a comprehensive solution for oss-review-toolkit#5365.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Currently, scanning in ORT is package-based, and project-packages are identified by "definition files" (like "pom.xml", "build.gradle", "package.json" etc.) in the directory tree. So all files and directories below a definition file are regarded as belonging to the project that the definition file defines. See:
So, the project spanned by
pom.xml
in the root directory is considered to "own" all files below the root directory, includingSUBPROJDIR_A/license-a.txt
,SUBPROJDIR_B/license-b.txt
andWEBDIR/license-w.txt
. This means that scanner findings in those file will get associated to the root project.However, when the scanner's view shifts to the projects in the subdirectories, the project spanned by
SUBPROJDIR_A/pom-a.xml
also gets the scan result forSUBPROJDIR_A/license-a.txt
assigned (similar for the other subprojects).This is historically so because ORT not really understand the semantics of a project's directory tree. However, the result can be really confusing, as scan findings (and potential violations) might show up multiple times in the reports, although they all stem from the same single file.
As a solution to this, one idea is to associate files always only to the nearest enclosing project when walking up the directory tree to the root. Maybe this logic should be limited to projects of the same type; however, in the example above this would result in the scanner findings from
WEBDIR/license-w.txt
to still be associated to the root project spanned bypom.xml
.I have some hopes that the required filtering logic would be easier to implement once #2668 is merged, as it implements some similar filtering to associate provenance-based scan results to individual packages IIUC.
The text was updated successfully, but these errors were encountered: