Don't declare sample plugin transitive dependencies

[MarkEWaite]

Don't declare sample plugin transitive dependencies

Removes the following transitive dependency declarations from the sample plugin:

• cloudbees-folder
• favorite
• pipeline-groovy-lib
• pipeline-model-definition
• variant
• workflow-basic-steps
• workflow-durable-task-step
• workflow-multibranch

Each of those plugins is already a dependency of another plugin declared in the pom file of the sample plugin. No need to declare the plugin if it is a dependency of an already declared plugin.

Attempting to follow the guidance from the README that says:

Avoid adding transitive dependencies to sample-plugin/pom.xml. It is supposed to look as much as possible like a real plugin, and a real plugin should only declare its direct dependencies and not its transitive dependencies.

Testing done

mvn clean verify passes as well as the variants using profiles like mvn -P 2.387.x verify

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main 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

[basil]

No need for full-test on this I think, since any changes to sample-plugin/ are already tested without full-test.

[MarkEWaite]

No need for full-test on this I think, since any changes to sample-plugin/ are already tested without full-test.

Thanks. I'll cancel the CI job, remove the full-test label, and run the CI job again.

[jglick]

Thanks. There is no rigid guidance for plugin POMs regarding transitive vs. direct dependencies. mvn dependency:analyze will have lots of false positives & negatives due to the complexities of plugin class loading, and the fact that tests often rely on the presence of some plugin (for example to define a Pipeline step) without ever referring to its types. As a stylistic matter I would normally keep a dependency like pipeline-model-definition explicit even if some other test dep happened to pull it in, if my tests in fact involved Declarative Pipeline; or variant only if I were actually using @OptionalExtension.