Check with m-enforcer for complete runtime classpath
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [x] I have signed the Adobe Open Source CLA.
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
Currently the build fails with
[INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce-complete-plugin-classpath) @ aemanalyser-maven-plugin ---
[WARNING] Dependency org.osgi:org.osgi.service.configurator:jar:1.0.0 (provided) via org.apache.felix:org.apache.felix.cm.json:jar:1.0.6 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.cm:jar:1.6.0 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.log:jar:1.3.0 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.coordinator:jar:1.0.2 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
[WARNING] Rule 0: org.apache.sling.maven.enforcer.RequireProvidedDependenciesInRuntimeClasspath failed with message:
Found 4 missing runtime dependencies. Look at the warnings emitted above for the details.
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?
https://github.com/adobe/aemanalyser-maven-plugin/issues/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?
....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 https://github.com/adobe/aemanalyser-maven-plugin/pull/164#issuecomment-1172036456.
[WARNING] Dependency org.osgi:org.osgi.service.configurator:jar:1.0.0 (provided) via org.apache.felix:org.apache.felix.cm.json:jar:1.0.6 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.cm:jar:1.6.0 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.log:jar:1.3.0 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
[WARNING] Dependency org.osgi:org.osgi.service.coordinator:jar:1.0.2 (provided) via org.apache.felix:org.apache.felix.configadmin:jar:1.9.24 not found as runtime dependency!
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. This change is also updating/changing dependencies. At this point these are aligned mostly with what is used in Apache Sling's CP2F converter.
Well, the issues #176 and #173 show that maintaining the dependencies manually doesn’t really work
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)