-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MINVOKER-318] - invoker:install must resolve deps in 'test' scope #169
Conversation
When integration tests require dependencies in "test" scope, that overlap with dependencies in "runtime" scope (e.g. the normal jar in runtime scope and a "tests" jar in test scope), the install goal will not resolve and install the test dependency because it requests only runtime scope resolution. This PR contains an integration tests to demonstrate the problem. The change is trivial: make the "install" goal resolve its dependencies in test, not in runtime scope.
3704630
to
51291a5
Compare
requiresDependencyResolution = ResolutionScope.RUNTIME, | ||
requiresDependencyResolution = ResolutionScope.TEST, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Project can have many items in test scope, some can be a big,
With it we will always copy items which will be never used in the more of case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the problem is that the current setup makes it impossible to run actual unit tests that have test specific dependencies which overlap with runtime dependencies.
Here is what I would suggest you should do: run the following commands:
git clone git@github.com:apache/maven-invoker-plugin
gh pr checkout 169
mvn clean install -Prun-its -Dinvoker.test=fail-test-scope
this will show you the integration test pass. Now change the resolution scope in src/main/java/org/apache/maven/plugins/invoker/InstallMojo.java
back to runtime. then run mvn clean install -Prun-its -Dinvoker.test=fail-test-scope
again
now you will see the integration test fail. It fails because the install plugin fails to install the commons-lang3-3.12.0-tests.jar
dependency in the local repository. Even though the dependency is required by the integration test pom.
what does not work
- force the dependency with
extraArtifacts
. Because the dependency is not present in the resolution scope, the plugin can not install it in the local repository. - move the dependency from "test" to "runtime" scope
This is a bug in the invoker:install goal. Here is a real world example:
git clone git@github.com:jdbi/jdbi3-guava-cache
cd jdbi3-guava-cache
./mvnw -Dbasepom.it.skip=false clean install invoker:install invoker:integration-test invoker:verify
This fails. Install the patched maven invoker plugin (with the fix applied), then run
./mvnw -Ddep.plugin.invoker.version=3.4.1-SNAPSHOT -Dbasepom.it.skip=false clean install invoker:install invoker:integration-test invoker:verify
The integration test now succeeds. This project is directly affected by the bug and its fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like you try to execute unit test by invoker,
but invoker is designed for executing integration test for Maven plugins not for unit tests ...
I don't think that it is a bug here.
During we testing plugins we don't need artifacts from test scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you feel that this plugin should only be used to run maven plugin integration tests, then it should probably be marked as an internal plugin that should not be used for any other use cases. Otherwise, the headline of the project reads The Invoker Plugin is used to run a set of Maven projects. The plugin can determine whether each project execution is successful, and optionally can verify the output generated from a given project execution.
. That is what I use it for (and others do as well). It executes maven projects (in my cases projects that run unit tests) and checks the outcome.
I gave you a bug report, an integration test and a fix. I am pretty sure that MINVOKER-314 and MINVOKER-317 are the same bug (In fact I know that 317 is the same bug).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
314 and 317 are something else ...
My proposition for resolving this PR is providing scope for install goal as new parameter with default value to runtime
So when we need in some case another scope you can change configuration for your project.
I hope that will be ok for you.
👎 from me, unless you convince me be more real example. |
@slawekjaranowski have you actually tried the examples that I gave you / can you reproduce the problems? |
@hgschmie - I have only looked at your example, I suspect that can fail as you wrote So we can introduce new parameter to have possibility to change scope for instal goal |
I don't think there is a point for me to discuss this any further until you tried the bug report examples that I gave you. I am glad that you accommodate the possibility that things "can fail as I wrote". As an amendment to -317, if check out The dependency resolution scope is declared by a plugin and then given to the core. I am not sure how one can add a parameter to change this. |
Project |
This PR doesn't resolve MINVOKER-317 in hgschmie/invoker-bug.git you have mixed two cases
You use I tryed:
and we will have:
|
We have discovered another bug here. When we have dependency which is part of reactor build, all attached artifacts from reactor project are copied, should be copied only listed as dependency. I think that this PR will change current behavior, which is correct in most of cases. We should resolve root cause not only one special case. |
Yes, it is git@github.com:jdbi/jdbi-guava-cache Apologies. |
Yes, you should. Except that the average bug on the MINVOKER JIRA is about three years open (there are bugs from 2014 open). You are failing your users. |
You as well since you are a committer too. Longer than me and Slawek. |
When integration tests require dependencies in "test" scope, that overlap with dependencies in "runtime" scope (e.g. the normal jar in runtime scope and a "tests" jar in test scope), the install goal will not resolve and install the test dependency because it requests only runtime scope resolution.
This PR contains an integration tests to demonstrate the problem. The change is trivial: make the "install" goal resolve its dependencies in test, not in runtime scope.
Following this checklist to help us incorporate your
contribution quickly and easily:
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.
[MINVOKER-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
MINVOKER-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean verify
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
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.