-
Notifications
You must be signed in to change notification settings - Fork 200
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
Support dependency configurations from java-library #127
Comments
This is because Gradle disallows resolving those configurations (see #125). I don't know why they did that. I'm hoping that cloning and setting the flag to allow will bypass this. We should probably ask to find out why, in case they'd prefer to revert in rc2/ |
Have you asked them? Do you need some help? |
Yep. I'm a little concerned that |
Adding @jochenberger, @oehme Two approaches seem to work. Both seem a little hacky. Disable Restriction
This calls a method only available since Gradle 3.3, so we'd have to check if the method is present first. I could also imagine this setting is disallowed later as perhaps not intended to be modified. Query with Detatched Configuration
and replace all usages of My concern here is that I have had poor experiences with copying and detached in the past. Now using a super configuration brings in another scenario that likely has bugs. In the past this has been unfixed bugs in repository handling and lately with dependency-management-plugin/ interaction with resolution strategies (caused by bugs in configuration copying). But I think this is more inline with @oehme's intent as he refactors Using the example shows both approaches work.
|
I'd go with the detached configuration approach, as it is closer to where we want to go in the long run (having a "Query" concept). If there are bugs handling detached Configurations, please let us know.
I did a quick search and couldn't find usages of |
Nevermind, GitHub search is broken, I found the places you were referring to. |
You won't need to change to |
There's not much I can contribute here in terms of what the best approach might be. But what I take away from this is that we should rewrite the tests to use TestKit to make it easier to test against different Gradle versions. |
See #129 |
Thanks @oehme and @jochenberger. We'll use the detatched configuration method. I'll try to find the time to wrap that up. |
I have a draft that passes the examples (this one, and in examples folder). But it fails on two unit tests, so some debugging is needed. It fails with a custom component selection rule and @jochenberger's TestKit tests. I suspect the detatched configuration isn't honoring the super configuration's resolution strategies which is causing the problems. |
You could just create a PR. Travis should build them and we can inspect the build failure and try to fix it. |
Travis builds all branches, but I can add one if it's helpful to iterate on. |
Resolution strategies only work on the configuration they are declared on indeed. If you need them then a copy is the only way. |
Yes, we try to honor the build's configuration. So we'll have to use the |
See #137 for a new PR. |
Gradle 3.4 RC introduces 'java-library' as a replacement for 'java'. Running 'dependencyUpdates' on such a project produces errors:
Also, the plugin fails to check the new configurations.
To reproduce use
build.gradle
withEach dependency in this file (except for the versions plugin) is outdated and should be reported. Currently only plugins,
compileOnly
andruntimeOnly
are checked.The text was updated successfully, but these errors were encountered: