Do not fail if optional plugin cannot be retrieved

[PierreBtz]

…f an optional plugin cannot be retrieved

Swallow the PluginNotFoundException if the dependency is optional.

Opening as a WIP PR, I'm not happy to have to do this this way but I'm not exactly sure how the optional dependencies are treated in the project, not sure why they are not skipped if they are causing trouble. Happy to discuss further to enhance the solution.
Once we agree on a solution I'll add tests.

Fixes #316

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[PierreBtz]

@timja I followed your advice and modify the getLatestPluginVersion directly. Not sure if this class is providing a public API for downstream projects so I kept the old method, let me know if it's ok to break compatibility and delete it.

[timja]

@timja I followed your advice and modify the getLatestPluginVersion directly. Not sure if this class is providing a public API for downstream projects so I kept the old method, let me know if it's ok to break compatibility and delete it.

🤷 no real policy on it here. I'm not aware of any tools embedding this that would update without getting a compile time error, but you can just deprecate it and can remove them in a major version sweep at some point.

[oleg-nenashev]

The assumption about optional plugins is not fully correct. We do care about the version if there is a conflict.

E.g. we may have plugins A depending on C:1.2:optional and B depending on C:1.1:mandatory. In this case dependency metadata download failure for A will lead to the installation of C:11 which might be binary incompatible with A and lead to the Jenkins startup failure.

I am fine with more relaxed rules for optional dependencies, but this one does not seem to be the best approach when enabled by default.

[timja]

I am fine with more relaxed rules for optional dependencies, but this one does not seem to be the best approach when enabled by default.

no options please, the current ones are confusing enough.

if it's optional we can ignore it, not sure if you can set the version number to be 'optional'?

[PierreBtz]

@oleg-nenashev good point but I'm not sure how the case you mention could happen given that if C is not proposed by the UC you will never be able to resolve any version, right? So in this use case, the CLI will fail anyway when resolving the dependencies of B.

no options please, the current ones are confusing enough.

+1 :)

[PierreBtz]

if it's optional we can ignore it, not sure if you can set the version number to be 'optional'?

Not sure I didn't read the whole codeline (yet :)) but I assume that if I return "latest", and there are two different versions to resolve at some point, the non latest one would win... so the proposed solution would be equivalent to specifying an optional version.

[PierreBtz]

@oleg-nenashev happy to improve this PR to get it over the finish line, would you mind giving me an example of what this PR would break, I'm not sure I can find one (see my previous answer for my reasoning: #317 (comment)).

[timja]

@oleg-nenashev ^^

[oleg-nenashev]

Sorry, I missed it