maven-hpi-plugin
maven-hpi-plugin copied to clipboard
resolve-test-dependencies fail to update classpath to use some optional transitive dependencies coming from hpi included in overrideWar
Signed-off-by: Olivier Lamy [email protected]
Unfortunately even if this approach the problem is resolve dependencies too deep
and try to get dependencies of bad old poms :( (bad metadata from the past)
as we are here in the case of some optional transitive dependencies.
but optional dependencies are not transitive so should not be present at all (so should not need updating).
Something seems fishy @olamy ? (only direct (non-transitive) optional dependencies should be updated, or I am missing something?)
as we are here in the case of some optional transitive dependencies.
but optional dependencies are not transitive so should not be present at all (so should not need updating). Something seems fishy @olamy ? (only direct (non-transitive) optional dependencies should be updated, or I am missing something?)
no of course optional dependencies are not transitive. But it looks there are some discrepancies between Jenkins plugins system (in PCT only?) and Maven dependencies (as you can read them in poms).
What I can see from the current case (issue from https://github.com/jenkinsci/bom/pull/3049)
before
mina-sshd-api-core
+- ssh-credentials
| \- trilead-api
after
mina-sshd-api-core
+- ssh-credentials
| @OptionalExtension(requirePlugins = {"trilead-api"})
| \- trilead-api (optional)
As we can think, optional is not transitive when running mina-sshd-api-core
tests in the PCT/bom context, the surefire classpath should not include trilead-api
and it doesn't, so the CNFE.
BUT and it looks to be the real problem, while the extension is marked as @OptionalExtension(requirePlugins = {"trilead-api"})
so you can you think as reading the poms this extension shouldn't be loaded as it's transitive optional.
But not Jenkins load because it can see the plugin but on the other side the classpath used by surefire doesn't contain the classes from trilead-api whereas it should.
So either we fix something in how Jenkins loads plugins in this case or we include the trilead-api in the classpath (i.e the transitive optional).
Or as a workaround we keep adding non-needed dependencies in poms just to hide the root cause. (such https://github.com/jenkinsci/mina-sshd-api-plugin/pull/91 and there are probably few more).
But this is a bit of a workaround and doesn't look right while reading the poms. PCT may have some requirements and different way of testing. But loading of plugins/extensions (respecting the annotation @OptionalExtension(requirePlugins = {"xxx"})
) should be consistent with the classpath calculation to run the tests.
loading of plugins/extensions […] should be consistent with the classpath calculation
In general, if you need to delve into this kind of detail, you should switch to RealJenkinsRule
.
root cause of this is https://github.com/jenkinsci/bom/issues/3231
Adding a workaround/fix here would not fully solve the issue and would leave plugins still needing test fixes specific to running in the OSS bom build with a fat war