Fix #324 Remove unnecessary manual dependency resolution

[srdo]

Please see #324

The fix here is to remove the manual dependency resolution in DependenciesTool. We already configure the mojos to require dependency resolution up to test scope, so all dependencies are already resolved and present in the injected MavenProject(s).

I realize that #219 calls for programmatic dependency resolution, but I think that will be easier to implement once the plugin is upgraded to newer APIs. For now, the code in DependenciesTool is unnecessary and causes this bug.

I'll put up a PR for upgrading to Maven 3 APIs soon, which will depend on this PR.

[srdo]

One of the builds on Appveyor failed, but it's not the test I added, and it doesn't fail for me locally or on Travis. The log on Appveyor just refers to the integration test build log. Do you have access to that log @ppalaga? I don't seem to be able to find it.

[ppalaga]

One of the builds on Appveyor failed, but it's not the test I added, and it doesn't fail for me locally or on Travis.

Appveyor is Windows. Do you use Windows locally?

The log on Appveyor just refers to the integration test build log. Do you have access to that log @ppalaga?

No, Appveyor, much like TravisCI has no notion of persistent workspace. The only way to debug this is to add type path\to\the\log to on_failure of appveyor.yml.

I pressed "rebuild" on the failed task, FWIW.

[srdo]

I use Windows, but through the Linux subsystem. It looks like the test passes now, maybe it is flaky on WIndows. I'll try running it a couple of times outside the Linux subsystem.

Regarding Appveyor, maybe we could store the target/it directory as artifacts on failure? https://help.appveyor.com/discussions/suggestions/828-store-some-artifacts-in-case-of-failure

[srdo]

Ran the tests 5 times locally on Windows with no failures. Maybe it was a network issue while downloading a license?

[ppalaga]

Maybe it was a network issue while downloading a license?

Yeah, that's my theory. Let me review this PR.

maybe we could store the target/it directory as artifacts on failure? https://help.appveyor.com/discussions/suggestions/828-store-some-artifacts-in-case-of-failure

A PR is welcome.

[ppalaga]

The changes look good at the first sight. Could you please reword the commit to Fix #324 Remove unnecessary manual dependency resolution so that the issue gets auto-closed upon merge?

Let me test with WildFly Camel now.

[ppalaga]

Does this commit have any potential to break the backwards compatibility?

[ppalaga]

Found no issue with WildFly Camel. This PR will be good to merge once you please reword to Fix #324 Remove unnecessary manual dependency resolution

[ppalaga]

My quick tests show this as a substantial perf gain on a project as large as WildFly Camel. I am getting build time 2:08 using this PR vs. 3:15 using version 1.20.

[srdo]

Thanks for reviewing.

Reworded commit message.

I wouldn't expect backward compatibility to be broken. The deleted code wasn't doing anything useful, I think, and any difference to the dependencies resolved by Maven was probably incorrect.

I'll take a look at the appveyor thing soon.

[ppalaga]

Thanks @srdo !