Fix compatibility between Buildship/Gradle and Groovy 2.5 #370
Comments
|
Specifically it seems groovy-eclipse is deleting compiled scripts from Gradles script cache. Downgrading resolved the issue for all users. |
|
I can't think of anything that would be interfering with Buildship/Gradle script cache. Is it using any org.codehaus.groovy packages? If importing via |
|
The issue is not about code running inside Eclipse. Buildship does not interact with Groovy at all. The Gradle daemon (a different process) compiles Groovy scripts into a cache. These files are being deleted and it seems that is happening because of groovy-eclipse. I have no idea why it would be doing that or how it would even find those classes. But downgrading to an older version of groovy-eclipse fixed the issue for our users, so there must be some obscure connection. I'll ask the users who reported that issue to provide more details, maybe they can debug a bit. |
|
Ok, so I'm running Eclipse 4.7.1a, and I reproduced it with the following steps:
Let me know if I can provide any further information. I'm not sure how exactly to interpret the contents of |
|
Does anyone have more detail -- an Error Log entry perhaps? The steps above worked for me using Gradle 4.3.1. |
|
One thing you can check: Are script filters enabled for
The presence in the list indicates that |
|
It only seems to happen when using Groovy 2.5 in Eclipse, maybe that's what's really causing the problem, not a change in the groovy-eclipse plugin per se. |
|
Sure enough, when I switch to Groovy 2.5 I get this exception: |
|
I personally do not have any problem to run even the latest Greclipse snapshot with Gradle up to 4.3 and Groovy 2.4.12, on both Oxygen.1 and Neon.3. |
|
Now the odd part is that the Gradle daemon is a completely separate process, so the version of Groovy used in Eclipse shouldn't influence what happens in Gradle. However, the error message above indicates that a compiled script has been deleted from Gradle's caches. |
|
I don't use Gradle daemon, unless its somehow started under the covers. How can it be confirmed that the class file was removed from the cache? I just ran refresh and the error popped.
|
|
Not sure if this helps anyone, but
|
|
Same error here. |
|
@regrog Can you confirm that command-line build with Gradle 4.3 and Groovy 2.5 fails (no Groovy-Eclipse in the picture)? |
|
Sorry, I omitted that.... |
eric-milles
changed the title
|
Same issue occurred in my case when I try to install groovy-eclipse snapshot plugin it breaks gradle, deleting cache resolve issue though. Is there any fix for this? |
|
I'm not really sure what the nature of the conflict is. There is a lot of speculation in this thread. But switching Groovy Compiler to 2.4 should be a viable workaround.
|
|
I saw you opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=532075 for Buildship. I don't think we need a second issue to discuss this (@donat and I are the Buildship team). Let's keep the discussion here. We don't know what Groovy 2.5 is doing, but it seems to delete compiled scripts from Gradle's cache. This is really odd because the Groovy version installed in Eclipse should have 0 influence on the Gradle daemon, which is a completely separate process with its own version of Groovy inside. |
|
There is not much I can do with this issue. It seems that the expectation is that I will dig in and figure out what is going on. Groovy integration is not doing anything with the Gradle caches. From what I looked at, the files are all there, but the hashes used are different and so it is seen as file not found.
|
|
Buildship run failed, I installed groovy-eclipse plugin, groovy compiler version is 2.6.0. Refresh gradle project error is here: And gradle crashed when switch groovy compiler version from 2.6.0 to 2.4.15. Gradle menu has been remove from project and task view and executions view were broken. It shows message on workspace startup: An internal error occurred during: "Decoration Calculation". And task view error message: Eclipse version Oxygen.3 Release, sts plugin version 3.9.3.201803200843-RELEASE, Eclipse Groovy Development Tools 3.0.0.xx-201804052043-e47 |
|
I'm running Eclipse 4.6.3. The workaround suggested here did not help. Today I updated all my plugins to try to cure an issue with running Cucumber tests and I hit this error. Tried removing and reinstalling Buildship - no help So right now my Eclipse is broken for the projects that I work on :( Tomorrow I will try installing from scratch with a more recent version and hope that gets me back to a working setup. |
|
`Thought that command line builds should still work... WRONG. They are broken too :( `>.\gradlew clean FAILURE: Build failed with an exception.
BUILD FAILED in 0s` So it looks like something is messed up with Gradle, even outside of Eclipse. Any suggestions for how to get myself out of this situation? |
|
Stopping the daemon should help. If that doesn't fix it, you'll have to clear out the cache in |
|
Thanks for your help - it got me out of the problem. For the benefit of others, here is what I did... I found a couple of gradle daemon (Java) processes using the Procexp tool and killed them. This tool lets me see the command line easily to find the right process. Killing the daemons did not fix the issue but it was a necessary step. The gradle internal files on my Windows 10 machine are in c:\Users\<username>\.gradle Below here is a directory 'caches' and below this are multiple directories with different version numbers. These correspond to the Gradle wrapper version. Below the version directory are several directories. The ones affected by this issue seem to be 'scripts' and 'scripts-remapped' So for example... I renamed these directories by adding an underscore to the end of the file name (this is easier to undo that deleting them). All of the gradle daemons need to be stopped before doing this. I repeated this for each version of the wrapper that has been affected and still in use by projects (I had more than one version in use) After doing this the problem was gone and I was able to run gradlew on the command line. The builds in Eclipse also started working again (but remember that I had previously uninstalled all of the groovy plugins - perhaps more than I needed to do but preventing groovy 2.5 from being used also seems to be a required step). In each case it took some time for the tools to rebuild their internal state - tens of minutes for Eclipse. To find the wrapper version... it may be visible in the Eclipse error dialog. If not, look at each project. Each of mine has a file 'gradle/wrapper/gradle-wrapper.properties' containing a setting distributionUrl which includes the version number |
|
Delete those directories will fix problem, they will re-create after next running. And.. must to run gradlew in command line once for each version(version number in properties)... Now it work fine with groovy plugin and compiler level 2.6... |
|
But I updated just yesterday and got groovy '2.5 (early access)' if I recall correctly... and walked unwittingly into a mess that burned up several hours to resolve. Is 2.6 in the auto update yet? Did I maybe hit this because my Eclipse version is not the latest? |
|
Just to clarify: Everything works with 2.6? |
|
No. It seems working just using the cache generated by command line, but not the plugin, get "BuildScript" when there is no cache(change file and rebuild). And Gradle wrapper version of new project is 4.3 always( I have selected wrapper to 4.7 in window->performance->gradle ). |
|
Hello,
After iInstalling GRECLIPSE from site http://dist.springsource.org/snapshot/GRECLIPSE/e4.8/ any gradle refresh on any project will fail with the error:
Changing the groovy compiler (2.4, 2.5 or 2.6 alpha) or erasing the .gradle directories both in project home as well as in gradle user home or changing the gradle release does not resolve. Only removal of GRECPLISE from Eclipse brings the system back to correct operation. In my case and in my environment it seems that coexistence of GRECLIPSE with buildship is impossible. Is this issue being looked into? Regards |
|
@donat I'd like to resolve this issue between Buildship and Greclipse. Are you the developer contact from the Gradle side? I've investigated to the best of my abilities and found that the |
|
@eric-milles yes, I am that person, although I won't be able to look into it this month as I'm just about to go on vacation. I'll investigate further once I come back. |
|
Something I just noticed is that when I comment this out in // enable InvokeDynamic support across the board
System.setProperty("groovy.target.indy", "true"); |
|
When I set this system property for Groovy 2.4, I get the same error. So the real issue is indy support and not Groovy 2.4 vs 2.5. |
- search for groovy "indy" jar within a project's GROOVY_SUPPORT (aka "Groovy Libraries") classpath container
|
Hi Eric, does your applied workaround prevent Eclipse/Gradle projects in the workspace to use Indy Groovy on their own classpath? Because I was using it regularly with no issue at all... |
|
@eric-milles Thank you for the analysis and glad you found a fix! @donat We should check why this could affect Gradle. Do we just pass all system properties to the daemon? |
|
@mauromol You can still use any jars that were compiled indy. If the Groovy Libraries classpath container is found for your project, indy will be enabled for compilation automatically. Otherwise, you will need to enable indy using a compiler config script. I could not find a quick way to access the Gradle project model; Buildship did not appear to expose it through an adapter or something else. I think this is how you enable indy compilation for the gradle build: |
|
@oehme or @donat Is it Buildship or the eclipse gradle plugin that creates/populates the |
|
@eric-milles Gradle provides the data model, Buildship configures the project from that model. So Gradle would have to add that "test" attribute.
It would be great if this was not bound to the Groovy container, since neither Gradle nor Maven use that. They provide their own classpath container containing the dependencies configured in the build. Why not look on the resolved classpath, matching on the "indy" in the jar's name? |
|
@eric-milles I do not use the Groovy container at all, I disabled it, I'm just configuring the Eclipse project classpath by adding the Groovy Indy jar to the compile configuration of the corresponding Gradle project (through the Buildship "project and external dependencies" classpath container). This should be enough to enable the Indy compilation (AFAIK... Am I wrong?). My question was due to the fact I had a quick look at your commit and I saw you're searching for the Indy jar in the classpath (to do something I don't know), so I was wondering whether your workaround weren't going to break my configuration. I can't check right now because I'm on holiday. |
|
@oehme Does Buildship expose computed Gradle model through an @mauromol and @oehme I was pressed for time and so I went for the quick check. If a project has Groovy Libraries classpath container and it contains There should be no breakage for any existing workspaces/projects. If you are using Groovy 2.5+ compiler within Eclipse, compilation may not use indy in all cases it did before. However, you may still enable it. And for the separate Gradle build, you would have already needed to enable indy from within |
You can't get the
That sounds like a reasonable workaround. |
|
The use case is to see if "indy" optimization option is set within I don't want to scan the file contents or deal with the many ways in which this may get set. It is probably better if the gradle eclipse plug-in pushes this state into the eclipse project settings instead. |
|
@eric-milles Currently it's a bit painful to implement, but that's about to change. We're going to implement a project configurator extension point for Buildship where external plugins can hook into the project synchronization and can access arbitrary information from the Gradle build. I can imagine dogfooding this extension point in Buildship and reading the I'm not familiar with the groovy-eclipse codebase, so what exactly should Buildship do with this configuration? |
|
What I was looking at doing was accessing the Gradle/Groovy model to see if compiler config was changed. If it was, the eclipse project could be auto-configured with a compiler config script. This would give closer parity between Gradle build and Eclipse build. |
|
I think I understand. Is there an API or a file where Buildship can configure the compiler config script for a project? |
|
Oh, you are thinking Buildship could do it? If "compileGroovy.groovyOptions.optimizationOptions.indy" is true, I was going to try and set preference "org.eclipse.jdt.core.compiler.groovy.projectFlags=2" (in |
|
Well, since the solution will be an extension, it can be implemented both in Buildship and in groovy-eclipse. On the second thought, the latter makes more sense. I can open a PR with the solution once the Buildship-side is ready. |
Based on following user report it seems that the latest groovy-eclipse version broke the Gradle support in Eclipse: https://discuss.gradle.org/t/seemingly-trivial-additions-to-build-gradle-cause--buildscript--error/24386/9 Are you aware any changes in the codebase that might be related?
The text was updated successfully, but these errors were encountered: