[MDEP-739] Dependency Plugin go-offline doesn't respect artifact classifier

[jvv-trackunit]

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes.
  MDEP-739
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MDEP-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MDEP-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  See description below
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

Description

The go-offline plugin maps Artifact and Dependency objects to DependableCoordinate, which are then downloaded.
In the conversion to DependenableCoordinate, the Artifact/Dependency classifier was not included, which caused issues similar to

org.eclipse.aether.resolution.DependencyResolutionException: org.springframework.cloud:spring-cloud-stream:jar:tests:3.1.2 was not found in <repository>.

Impact

The dependency:go-offline is used to prepare maven dependencies in our CI system to allow share dependencies between different steps in our build pipeline. This bug currently breaks our CI pipeline.

Rolling back to maven-dependency-plugin version 3.1.1 is not an option due to MDEP-204 and other workarounds require republishing artifact without a classifier, which is also not desirable.

[michael-o]

Wow, this seems like an obvious one...

[elharo]

1.8 at the latest, I suspect

[jvv-trackunit]

MDEP-739 is not caused by a specific Java version, so any version should work.
I just tried removing this line from the code and the test still passes.

This line is here because I copied one of the other integration tests. I tried creating a test for the go-offline mojo using AbstractMojoTestCase included in org.apache.maven.plugin-testing:maven-plugin-testing-harness:3.1.0, but I ran into issues with fields that the testing harness did not set.

[jvv-trackunit]

I just committed the removal of the line above. I amended the change to the current commit since I noticed the project usually ask people to squash their changes.

[jvv-trackunit]

Thanks for the review @elharo !

I am trying to figure our whether I should release/publish my changes as an artifact in my own organization or if I should wait for this PR to be part of an official release. I would prefer the latter, but I am unsure what timeline I should expect.

I have read the maven project release procedure but it does not specify when a vote for release should be initiated.

It seems there have been a lot of changes since the official 3.1.2 release. Version 3.1.3 was not a public release - its not present on the official plugin page and not in the public maven repository either.

Would it make sense to initiate a vote if this PR is merged?
@slachiewicz

[elharo]

3.1.3 has not been released. The next release should be 3.1.3. It will happen when someone volunteers to do it or pays someone else to do it.

[jvv-trackunit]

I assume that I cannot volunteer to do a release, since I am not a committer. Please let me know if this is not correct.

How does the "pay someone else to do it" option work? Where do I connect with someone that can do it? How much work goes into a release?

[slachiewicz]

I'll do the release and prepare the vote by end of this week.
https://maven.apache.org/developers/release/maven-project-release-procedure.html

[elharo]

Practically committer access is not enough. It really requires a PMC member for several steps. (I am not one.)

There's no formal process or schedule for deciding to release. You just need to convince a PMC member to call a vote and release it if the vote passes. Non-PMC committers can do some of this, but I don't recommend it.

[elharo]

Also a lot of work goes into pushing a new release. It is not a trivial process. When I had employer support for some of this work a year ago, it took multiple hours of work, and days of calendar time per release. It's probably easier for a PMC member since there are fewer steps where they'd have to wait for the PMC member to respond.

[jvv-trackunit]

@slachiewicz Thanks for your help.

[jvv-trackunit]

@elharo Thanks for the insight into the release process - the effort that goes into a release is often invisible to the outside. I'll keep this in mind for future pull request.

[michael-o]

@van-vliet How crucial is is change for you?

[jvv-trackunit]

@michael-o I am not sure how to describe the cruciality to you. I can describe the impact of not seeing this change released:

My colleagues and I have a couple of projects that encounter this issue. Without an official release, we have the following options:

1. Change our CI pipeline so it does not use go-offline
2. Re-release dependencies that have a classifier with a new name and no classifier
3. Release a forked version of the maven-dependency-plugin and use that in our CI pipeline.

Option 1 is a huge task that will affect all of our builds and will require a lot of work.
Option 2 is possible since we have only seen this issue with a single dependency so far. Version bumps and other dependencies with classifiers will make this option unsustainable in the long term.
Option 3 would fix the issue, but would require maintenance until we can switch back to an official release. We have no interest in maintaining a fork with just a single bugfix.

Neither options are good for us. They all require a significant amount of effort to implement. Without an official release, we implement the least effort workaround, which is probably is option 3.

MDEP-739 was reported by someone else, so at least one other person has encountered the issue and would benefit from the change.

[michael-o]

@van-vliet Vote is out. I accept donations ;-)