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
Return null for module name when extraction fails #30
Conversation
As detailed in https://issues.apache.org/jira/browse/MJAVADOC-609, module name extraction can easily fail, due to a legacy jar having a file naming convention that doesn't match what ModuleFinder expects, when determining an automatic module name from the file name. This failure to determine the automatic module name should not cause the jar to be missing from the resulting class path. This patch handles the FindException that ModuleFinder throws when looking for module descriptors, and returns null, indicating no name. This should allow the jar to still be added as a class path element, even though it can't be added as a module path element. Named modules won't be able to use the jar from the module path, but automatically named modules should still be able to use the jar from the UNNAMED module on the class path. Also: * Update LocationManagerIT to test the change * Make the LocationManager perform strict check for file existence * Fix broken LocationManagerIT tests (references to non-existent test/resource/dir.* directories) revealed by strict file existence checks in LocationManager
I'm not really happy with this proposal. Now it will always swallow the exception in case of an invalid filename, whereas the exception contains proper information what the issue is. |
The change attempts to determine the likely cause of the We could make that "likely reason" check more precise, by checking the file name against the regex described in the For what it's worth, I made several earlier attempts to preserve the exception and add the path item to the class path elements, but those attempts broke many more tests, and required a larger code change. In the end, I came to the conclusion that the exception shouldn't have been thrown from To be honest, I'm not 100% comfortable with swallowing the exception this way either. I'd be much more comfortable swallowing a subclass of The main reason I care about this is because of the impact on MJAVADOC-609, so if this solution is rejected, I'd be happy to help review/test other solutions (here or in |
Let's fix it at the |
@rfscholte Okay, sounds good. |
In that case, it looks like the pull request in apache/maven-javadoc-plugin#35 is what I would have come up with. |
As detailed in https://issues.apache.org/jira/browse/MJAVADOC-609,
module name extraction can easily fail, due to a legacy jar having a
file naming convention that doesn't match what ModuleFinder expects,
when determining an automatic module name from the file name.
This failure to determine the automatic module name should not cause the
jar to be missing from the resulting class path.
This patch handles the FindException that ModuleFinder throws when
looking for module descriptors, and returns null, indicating no name.
This should allow the jar to still be added as a class path element,
even though it can't be added as a module path element. Named modules
won't be able to use the jar from the module path, but automatically
named modules should still be able to use the jar from the UNNAMED
module on the class path.
Also:
test/resource/dir.* directories) revealed by strict file existence
checks in LocationManager