kriegaex commented on pull request #104: URL: https://github.com/apache/maven-shade-plugin/pull/104#issuecomment-873361152
> side note: a real fix would be to handle folders no, does not sound crazy? I agree, which is why I raised the question in the original PR and also CC in the Jira issue: >>> The more important question I have is: Is it necessary to do the same analysis and exclusion for used services during minification for files in a `target` directory on the classpath, which currently happens for JAR files, or is it the right thing to just ignore it? Is a classpath directory a valid use case here? It could very well be the case, because the current module's class files are usually part of the uber JAR if not explicitly excluded by a filter. So we would have to mimic the same logic here. I can try doing that, starting a fresh PR superseding this one. But I want a maintainer's qualified answer before I start potentially wasting time with a superfluous feature. Also [in the Jira issue](https://issues.apache.org/jira/browse/MSHADE-366?focusedCommentId=17350890&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17350890), @JanMosigItemis replied: >> I'd say, to make things more straight forward, we should do the "quick fix" for the warning and the (maybe) new logic in different PRs, so that we get fast results but do not mix things up here. I wanted to respect his suggestion and still am. To expand this functionality to class file directories too, would still be a goal for the future. This is e.g. why when factoring out method `scanServiceProviderConfigFile`, I decided for it not to take a `JarEntry` parameter, but simply a `BufferedReader`, so later it can be reused for service loader config files found in file system directories. Probably, further refactoring to unifie the two approaches is possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
