Cannot execute null+configuration #297
Comments
|
I got the similar error for Ratpack framework ... shadow 1.2.4 works fine with same version |
|
I too got the |
|
Same here for |
|
@boris-petrov is that all that's in the |
|
and can someone post a full stack trace by running the build with |
|
@johnrengelman - my |
|
I reduced my build.gradle to this, and the problem still occures running gradle shadow gets the following
|
|
Thanks. Will take a look soon. |
|
Ok, so it is related to order. First you don't know both |
|
thank you very much! yes, I can confirm removing java in that list of plugins fixed it |
|
Thanks! |
|
Gradle 3.5. I'm also getting this error, but it seems to be related to configuring There are two subprojects and a main project. I can configure the subprojects to use the plugin independently, but the main project script has the This is the minimal failing script: The stack trace is similar to the one above: |
|
Same error here: adding a source set will trigger the problem. |
|
My plan is to get to this is this weekend. |
|
@johnrengelman if you do this, you're basically overwriting the default classpath. I think it's not the right way to do. This is how the compile classpath of a source set is effectively set. So as a first fix, I would change your plugin to tell that the After that, I think it would be valuable to add stronger modelling, just like the |
That's a compile task, not a sourceSet. Compile tasks are configured by convention and you generally shouldn't need to touch them to add more dependencies. Instead, as @melix pointed out, you should use |
melix
added a commit
to melix/jmh-gradle-plugin
that referenced
this issue
Jun 1, 2017
Note that this version would only be compatible with Gradle 4.0+ and Shadow plugin 2.0+. It makes use of the new worker API, which avoids us doing all the nasty jar repackaging of the runtime of JMH: a worker process is automatically spawned by Gradle with the appropriate classpath. This means that we can compile this plugin with a specific version of JMH, but the user can override the version, and we would still use the `Main` entry point instead of an exec task to execute the benchmarks. This commit also fixes the [warning issued by Gradle 4.0](#94), which is the main reason for broken compatibility with released under 4.0: the newer API doesn't exist on 3.5. This commit however breaks a test with the shadow plugin, and is waiting for the resolution of [this bug](GradleUp/shadow#297).
Choonster
added a commit
to Choonster-Minecraft-Mods/TestMod3
that referenced
this issue
Jun 12, 2017
-- Can't update to Shadow 2.0.0 due to GradleUp/shadow#297
|
+1, though solved, by ordering plugins Switching from 1.2.4 to 2.0.0 with plugins in this order: Results in: However, the build succeeds if the plugins are reordered: |
|
@johnrengelman do you have any ETA on this bugfix? The JMH plugin is basically blocked on it. |
|
@melix trying to find the time to dig into it. You're suggestions above wouldn't work for shadow. It would cause those dependencies to be merged into the final jar, which is not the intent of the The intent was to automatically wire the compilation tasks with the |
|
@melix nevermind on my comment above - i misread what you wrote. Ok, let me try the |
|
This is fixed in 2.0.1 which is now available. |
|
Excellent, thank you! |
|
thank you very much! |
|
Thanks for fixing this issue John. I use Gradle, but don't really want to become a Gradle developer just to use it. Weird Gradle-related errors are just annoying. :-) |
|
I am facing same issue for android. I haven't applied java, groovy plugin |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Gradle version is
3.4.1. With the following (part of)build.gradle:I get:
This didn't happen with
1.2.4. I've no idea what that error is or how to debug it. Please advise. :)The text was updated successfully, but these errors were encountered: