Revert "Use resolve() method that actually throws exception."

[mbien]

This reverts commit e2a14bf, targets delivery

fixes #6222 ArtifactResolutionExceptions when working with maven projects

regression reproducible in RC1, see issue

[mbien]

tested:

• fresh config
• open maven-indexer parent https://github.com/apache/maven-indexer/
• open all sub modules
• open a pom, let nb index local repo, allow remote indexing of the ttwo suggested repos (central, apache snapshots)
• check that the basics work, add dependency, version completion, SMO class search, new hello world project + build, etc
• check for no exceptions, no error annotations in editor

INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: Indexing [scan] of local took 111.81s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: Indexing [download, create] of central took 617.41s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: Indexing [download, create] of apache.snapshots took 41.38s.

[sdedic]

I don't think that just throwing out a change is a good idea; without the change, the resolve method actually does not report ArtifactNotFound resolution failures (it returns artifacts that have isResolved() == false) and does not respect well recorded artifact origin (which was the reason for changing the implementation). In addition, the reason of inability to resolve the artiact (isResolved() == false) is discarded during the course.

I an on vacation with limited access to net/PC, and not really able to make a change until Sun 23; an option would be to have two resolve() methods - one broken retaining the old behaviour, the other the corrected one

[mbien]

I am sure there are good reasons to propagate the exception down to the API users but this can't be simply enabled without making sure all API users are prepared for this change. Thats why this is causing regressions. I don't want to start fixing things during the RC phase which weren't quite ready for inclusion, we can apply this again for NB 20 and stabilize it there.

[neilcsmith-net]

I don't think that just throwing out a change is a good idea;

Personally, I'm in favour of fast revert on regression, on both master (which is always meant to be release ready) and especially on delivery. Then introduce the corrected change via another PR taking care to review against the regression. Otherwise, some things become harder to revert later.

In short, +1 to this PR, and we should take this approach more often.

[matthiasblaesing]

I build this branch and my test cases still load clean (no excessive CPU use).

For the stacktrace I think the non-throwing behavior of MavenEmbedder#resolve masked a bug in NBRepositoryModelResolver.resolveModel, but I agree, getting this back into the know state is better, than having this bug.

[neilcsmith-net]

Tested the dev build with a few clean starts and seems to address issues I was seeing when opening projects.