Skip to content
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.

Sign up for GitHub

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

Jump to bottom

ClasspathScanner#determineSubpackageName sometimes resolves to wrong subpackageName starting with '...' #2612

Closed
1 task
hosuaby opened this issue May 10, 2021 · 5 comments · Fixed by #2613
Closed
1 task

ClasspathScanner#determineSubpackageName sometimes resolves to wrong subpackageName starting with '...' #2612

hosuaby opened this issue May 10, 2021 · 5 comments · Fixed by #2613
Assignees
@sormuras
Labels
component: Platform type: bug
Milestone
5.7.2

Comments

@hosuaby
Copy link
Contributor

hosuaby commented May 10, 2021

This bug was introduced in JUnit 5.7.1. 5.7.0 have no such a problem.

Example:

Path baseDir = "/com/fasterxml/jackson/core/base/";
Path classFile = "/com/fasterxml/jackson/core/base/ParserMinimalBase.class";
String subpackageName = determineSubpackageName(baseDir, classFile);
// subpackageName now equals "...base"

The bug is probaby due to commit #2531 (Fix package path computation in ClasspathScanner )

I got this bug because I use ReflectionSupport#findAllClassesInPackage inside my JUnit Jupiter plugin.

Steps to reproduce

To reproduce the bug is quite a trick. So project https://github.com/jlrosa/testwithresources was created. Here the steps to do

  1. Clone the project, execute mvn clean install, and open the project in IDE.
  2. Setup a breakpoint in ClasspathScanner#processClassFileSafely line 131.
  3. Run the test InjectResourcesTest in debug mode.
  4. Java debugger will stop. Check the value of the variable fullyQualifiedClassName. It will be something like: "com.adelean.inject.resources.junit.jupiter....jupiter.WithJacksonMapper"

Context

  • Used versions (Jupiter/Vintage/Platform): JUnit 5.7.1
  • Build Tool/IDE: Intellij

Deliverables

  • ...
@sormuras
Copy link
Member

Thanks for the report and the reproducer, Alexei.

I recently reopened #2500 in order to find a better fix -- my current plan is to revert #2531 first and write a dedicated ModulepathScanner.

@sormuras sormuras self-assigned this May 10, 2021
@sormuras sormuras added this to the 5.7.2 milestone May 10, 2021
@sormuras
Copy link
Member

The URI https://github.com/jlrosa/testwithresources is wrong. Typo?

@hosuaby
Copy link
Contributor Author

hosuaby commented May 10, 2021

@sormuras Sorry, I forgot that project is private. I will ask author to make it public.

@hosuaby hosuaby mentioned this issue May 10, 2021
Closed
@hosuaby
Copy link
Contributor Author

hosuaby commented May 11, 2021

Hello @sormuras .

Here the repository that can be used to reproduce the bug following steps above:
https://github.com/hosuaby/junit-bug-2612

sormuras added a commit that referenced this issue May 11, 2021
@sormuras
Fix package path computation in ClasspathScanner
22c6e1b 
Fix `getRootUrisForPackage()` in class `ClasspathScanner` by looking for two
"wordings" of a package name.

For example, package `foo.bar` is expanded to `foo/bar` and `foo/bar/`.
The latter allows find package `foo.bar` in a module called `foo.bar`,
and not `foo`.

Fixes #2500
Fixes #2600
Fixes #2612
@sormuras sormuras mentioned this issue May 11, 2021
Merged
7 tasks
@sormuras
Copy link
Member

Perfect timing, Alexei! I'll include it (or a similar check) in the PR I just submitted.

sormuras added a commit that referenced this issue May 12, 2021
@sormuras
Fix package path computation in ClasspathScanner
c62cd6a 
Fix `getRootUrisForPackage()` in class `ClasspathScanner` by looking for two
"wordings" of a package name.

For example, package `foo.bar` is expanded to `foo/bar` and `foo/bar/`.
The latter allows find package `foo.bar` in a module called `foo.bar`,
and not `foo`.
This commit also ensures, that there's no regression (compared to #2531)
by launching test runs using the standalone artifact with `--select-package`
and `--scan-class-path`.

Fixes #2500
Fixes #2600
Fixes #2612
marcphilipp pushed a commit that referenced this issue May 13, 2021
@sormuras @marcphilipp
Fix package path computation in ClasspathScanner
cf9c8fd 
Fix `getRootUrisForPackage()` in class `ClasspathScanner` by looking for two
"wordings" of a package name.

For example, package `foo.bar` is expanded to `foo/bar` and `foo/bar/`.
The latter allows find package `foo.bar` in a module called `foo.bar`,
and not `foo`.
This commit also ensures, that there's no regression (compared to #2531)
by launching test runs using the standalone artifact with `--select-package`
and `--scan-class-path`.

Fixes #2500
Fixes #2600
Fixes #2612
runningcode pushed a commit to runningcode/junit5 that referenced this issue Feb 15, 2023
@sormuras @runningcode
Fix package path computation in ClasspathScanner
be2177d 
Fix `getRootUrisForPackage()` in class `ClasspathScanner` by looking for two
"wordings" of a package name.

For example, package `foo.bar` is expanded to `foo/bar` and `foo/bar/`.
The latter allows find package `foo.bar` in a module called `foo.bar`,
and not `foo`.
This commit also ensures, that there's no regression (compared to junit-team#2531)
by launching test runs using the standalone artifact with `--select-package`
and `--scan-class-path`.

Fixes junit-team#2500
Fixes junit-team#2600
Fixes junit-team#2612
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sormuras sormuras

Labels
component: Platform type: bug
Projects
None yet
Milestone
5.7.2
Development

Successfully merging a pull request may close this issue.

Fix package path computation in ClasspathScanner junit-team/junit5
2 participants
@sormuras @hosuaby