I have a Gradle build that is failing “because no repositories are defined”. The buildscript for this build does not define any repositories, however this is a “sub-build” (i.e.
task foo(type: GradleBuild) that runs after the main projects are built, so I know that all the dependencies for the test build are already in Gradle’s caches but it will not resolve them.
I did try declaring
mavenLocal() but this ONLY checks
~/.m2 and fails to locate dependencies, even if I can see them in the Gradle cache.
Tried this with and without offline mode.
Anybody doing anything similar and know how to tell Gradle that it’s already cached the dependencies it’s looking for?
The Gradle cache isn’t a repository, so there’s not a way to specific it as such.
What are you trying to do? It sounds like a bad idea to rely on one build to cache the dependencies required for another.
As well as the JAR of our library, as part of the build we generate some “example” projects that ship with it that shows clients how to use it. The second Gradle build (the one that’s a task on the main build) is supposed to compile the example project we’ve just generated against the JAR we’ve just built for a smoke test.
The main JAR shades its own dependencies, so the example projects need to define their own 3rd party dependencies,
The main JAR is always built first, and the examples projects will never depend on anything the main project doesn’t depend on, which is how I can be so sure that dependencies are already cached - it’s just a case of getting Gradle to use them.
Under normal circumstances you still need to declare the repository even it is the last subproject in the lifecycle. Gradle will find it in the cache for you automatically.
So here might be a trick that cold work for you circumstances addressing two issues:
- For your example build you need to have the shaded JAR on the dependency list, but you do not want to direcly expose it the example build.gradle file
- The customer might need to find your JAR somewhere, so the example build.gradle file could have a repositories block that is commented out, for the customer to uncomment if need be.
You could add an initscript that is passed to the subtask via a
GradleBuild task is supposed to support this. Your initscript simply contains something like
All you need to do is generate the initscript before invoking the
doFirst might be the place).
Disclaimer: I just thought about this on the moment. It might work, but chances are good that you’ll need to play around a bit. The
GradleTest okugin uses something similar to injecy local dependencies into the project under test. The difference there though, is that
GradleTest fires up a second JVM, unike