-
Notifications
You must be signed in to change notification settings - Fork 20
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
Check with m-enforcer for complete runtime classpath #164
base: main
Are you sure you want to change the base?
Conversation
Currently the build fails with
To me those look like valid missing dependencies, but I am not sure whether there is a code path which actually relies on those. |
@bosschaert Any opinion/feedback on this PR? |
Hi @kwin what problem is this PR aiming to address? |
#113 is one of the issue which would be solved, but also it checks that the referenced runtime dependencies (those which count during maven plugin execution) have the right version (i.e. the version the underlying dependencies were developed against). Further insights in https://github.com/apache/sling-maven-enforcer-rules#require-provided-dependencies-in-runtime-classpath-since-version-100. |
Seems useful @kwin ! One concern is that there is a big long list of excludes which might be tricky to maintain? |
IMHOn less maintenance effort than always manually going through all transitive provided dependencies to check if some other dependencies need to be made available at run time :-) Also this PR fixes some actually wrong version which might easily break code at runtime if some downstream dependency relies on a method which has only been added in a newer version. |
Ok - sounds good. I once it's not marked as 'Draft' any more I'm happy to approve. |
You would need to check the current warnings as outlined in #164 (comment). |
I don't think we need a runtime implementation of the configurator, configadmin, OSGi log service, OSGi Coordinator for the maven plugin. |
I'm also worried by the long exclude list, in addition, the dependencies that are mentioned are not needed. So the marking of dependencies seems to be wrong. |
There is no flawless approach, look at the issues we had with the here suggested approach in Apache Sling, for example the feature launcher. In the end we are exchanging one imperfect way with another. It requires automated testing to verify that everything is still working |
The approach of manually maintaining all necessary artifacts does not change at all with this PR. Also more automated tests definitely help. The only thing which is proposed here is a Maven plugin giving some hints on how to make the class path more complete (granted, with false positives but compared to no help at all this is imho still an advantage) |
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: