-
Notifications
You must be signed in to change notification settings - Fork 461
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
gradletest can't download dependency #256
Comments
Good question! I've never fully understood this myself. @scphantm For your information, what the dynamic dependency download is doing is it's trying to download the formatter library used by Currently, behind-the-scenes, this dynamic downloading is achieved with a single detached configuration per dependency. I wonder if each of them could be replaced with a named configuration e.g. "spotlessGreclipse", without forcing each dependency to be downloaded earlier than strictly necessary. @nedtwigg Thoughts? |
Are those repos project repos or buildscript repos? Spotless downloads from the buildscript repos, which can cause some confusion. The history and consequences of this started in #99.
They definitely could, but it'd be pretty big change, and probably require a major-version bump and should be discussed in a new issue, iff somebody wants to take that on. I think that approach has some sizable downsides w.r.t. to documentation and portability. |
oh the master init file has both buildscript and normal dependency blocks. im just kinda confused why its not picking it up in the gradletest script. but ive never seen anyone do a dependency like you guys did, so im still a little confused. i will tinker with it today |
i see whats going on now. gradleTest has a lot in it to increase performance of the tests. For example, my plugin has over 300 gradletests in it. So to increase performance, the gradleTest runtime goes out and downloads the dependencies into the .gradle cache at the beginning of the run, then it rewrites a new init.gradle file that it injects into the test run. this init.gradle file eliminates all the repositories and sets everything to file from the cache, that way you don't waste time with the tests searching mvncentral 300 times. What that does for this plugin is since this plugin uses a rather non-standard way of downloading dependencies, since gradletest nukes the repos, it can't pull down the secondary dependencies you are looking for. Pretty sure this is going to take a while to fix. I am probably going to have to put a patch into gradletest so that i can add repositories to that init file. But that will be a hard sell. |
Spotless works with many formatters that each require conflicting versions of various dependencies. By provisioning jars for each formatter individually, and running them in their own classloader, we can support many versions of many formatters all in one plugin. We're not doing it just to be difficult :) If you'd like to submit a PR to improve Spotless to use named configurations rather than improve gradleTest, we'd be happy to merge. The improvement to spotless would be a fair amount of work, but if gradletest is hard to patch then maybe it'd be worth your time. |
Oh I get it. One design change I made blew up for trying to load groovy 2.3, gradle runs 2.14. Since it works in its own thing, gradle wasn’t able to resolve the dependency with resolution rules. I get why you did it. Just excercising my right to not be happy about it. ;) I’m a core dev for gradletest and know that project well. I can knock that change out fairly quickly over the weekend. And I don’t have to learn another code base. You should check out gradletest. It allows you to write gradle test kit tests as basic build files. It’s pretty awesome. |
in case anyone is wondering, i made the changes to gradletest to do this, we are working on building it now. but i had setup spotless to be disabled when the CI server runs the tests. What happened is with this thing dynamically downloading files, each time, it added over an hour to our unit test run and was blowing up circuit breakers. |
using the very basic example in my enterprise plugin system. whenever i try to activate any of the groovy features, my gradletests spit this error.
Why is this trying to dynamically download this dependency? Why isn't it built into the normal dependencies?
we run a custom version of gradle that has its own init with these repos in it, but it looks like your system doesn't pick those repos up when run inside a gradletest.
If you're just submitting a feature request or question, no need for the above.
The text was updated successfully, but these errors were encountered: