Bump maven-artifact from 3.5.0 to 3.6.3

[dependabot-preview]

Bumps maven-artifact from 3.5.0 to 3.6.3.

Commits

• cecedd3 [maven-release-plugin] prepare release maven-3.6.3
• f8bd6d5 [MNG-6771] Fix license issues on binary distribution
• c82409a [MNG-6759] Maven fails to use <repositories> section from dependency when res...
• 6fa256d update copyright year
• 88591a7 [MNG-6584] upgrade Wagon to 3.3.4 to get reason phrase handling back
• 53ccee3 [MNG-6778] use https for schema location
• d657c9c [MNG-6778] - Use https for maven schemaLocations
• 0c7c69f [MNG-6778] - Use https for maven schemaLocations
• bd10f00 [MNG-6789] upgrade and configure plugins for Reproducible Builds
• 3a80ae0 [MNG-6799] deprecate StringSearchModelInterpolator and remove @Named
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking Bump now in your Dependabot dashboard.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in the .dependabot/config.yml file in this repo:

• Update frequency
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[coveralls]

Pull Request Test Coverage Report for Build 889

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 55.791%

---

Totals
Change from base Build 887:	0.0%
Covered Lines:	1710
Relevant Lines:	3065

---

💛 - Coveralls

[rantoniuk]

@dependabot recreate

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[rantoniuk]

@olamy any doubts here?

[olamy]

this artifact is used as well by maven-plugin so depending if users use both plugins and classloading in Jenkins maybe we will have 3.5.0 or 3.6.3 :)
so merge it but it will not be predictable we use this new version or not..
Anyway we use only 1 class o.a.m.a.v.ComparableVersion and there is no much changes between those versions
this upgrade doesn't bring real values
but if a bot said to do it :)

[rantoniuk]

Oh..
This is quite frustrating as this argument can be used with pretty much any plugin and any dependency so that looks like the plugin system / class loader is poorly designed ;-(
I looked at the following stuff again:

• https://www.jenkins.io/doc/developer/plugin-development/updating-parent/#understanding-requireupperbounddeps-failures-and-fixes
• https://www.jenkins.io/doc/developer/plugin-development/dependency-management/
• https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

And here are my ideas:

1. add dependabot to Jenkins maven-plugin as well and set it both here and there to bump security updates only - I think this is the most reasonable approach as it will ensure (automatic) version parity in both plugins + security handled - but only for the patch version. If someone updates the minor/major in maven-plugin, it would need to be bumped here manually anyway.
2. depend in jira-plugin on the jenkins maven-plugin - but that seems like an overhead
3. add maven-artifact dependency to https://github.com/jenkinsci/maven-plugin/blob/master/pom.xml and and pom import dependency to it in this plugin - I never used this but this seems like a solution to this issue?
4. just merge it as is and don't worry about it now.

I'm ok with 4) but I'm curious what do you think about the other approaches as I saw you're quite active in maven-plugin recently.

[olamy]

frankly all dependabot magic need manual review.
I don't see any added value EXCEPT when a dependency has a security issue otherwise it's just a toy...
look at this case. We use only one class of the jar. Is there any changes in this class does it worth the upgrade?
are we/you running the PCT to be sure we do not break something when upgrading a dependency or change anything here?

Regarding the poorly designed comment I don't want to comment on that. Jenkins previously named Hudson exists since 2004 so yes there are decisions made in past which are maybe obsolete now but c'est la vie we need to live with that even Java sdk/core made bad design decisions but almost all class/methods are still there (marked as deprecated) and this is why it still works and used a lot so we want to apply the same rule. Well I agree it can be complicated but it can be a reason the success.

[dependabot-preview]

OK, I won't notify you again about this release, but will get in touch when a new version is available.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.