-
Notifications
You must be signed in to change notification settings - Fork 194
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
Building project with multiple grabs in different files takes an extremely long time to build (sometimes 3-5 min and sometimes eclipse just gets stuck at buildingWorkspace) #251
Comments
Can you open the Groovy Event Console and see if there is anything being written at the time of the blockage? Also, are there any entries in your workspace/.metadata/.log file at the time of this or just prior? |
During one of the eclipse workspace lockups I had the groovy event console opened and caught this. The timing of ~2 minutes is about the time that eclipse was locked up
|
In your workspace/.metadata/.log file, is there any more of the ConcurrentModificationException stack? It appears Ivy is trying to grab you library and is failing. Do you have the jar and whatnot added to ~/.groovy/grapes/com.leveldata? |
Here's me adjusting the version a bit just to see what happens. groovy event log dump:
In the workspace/.metadata/.log I don't see anything around that time frame, and overall there are only few traces but they were hours before and look to be something to do with eclipse updates. Just in case it's still useful https://gist.github.com/visch/0c5b6d6201fcc53244571e2670584bf3 The ~/.groovy/grapes/com.leveldata does have the latest version of our library pulled down. And the date modified on the ivydata-* files looks to be correct. |
Whatever is behind that co-mo exception seems to be the thing that is blocking. Too bad it is not logged better. You can try enabling Grab logging to see if that gives a better picture. http://docs.groovy-lang.org/latest/html/documentation/grape.html#Grape-Logging |
Haven't verified this yet but from some quick testing this might be much faster when we point to a mapped drive instead of to the DNS/ShareName (Facepalm) . I'll look at the additional Grape logging and let you know. Thanks for the help thus far! |
Ivy and by extension Grab can be very tricky at times. Once it is up and running it is quite nice to have, but as you have experienced, it can fight you to the finish. |
I enabled the extra Grape logging, but could only get output in my main console when I would run one of my applications. The lock happens not only when running a script, but also when changing the grab statements. I checked the workspace/.metadata/.log and didn't see any output. Here's another groovy event log output when we have multiple packages with grabs https://gist.github.com/visch/f86c2281cff885dea88942328212e230 instead of with just one. Is there anyway to disable grapes/grabs happening with the groovy-eclipse plugin? We're working on migrating away from this anyways and it might be easier for us in this case. Probably irrelevant but thought I'd share: |
You can also try adding "-console -debug" to the command line of eclipse and see if the error is written to stdout or stderr. |
From the linked thread, the concurrent modification exception appears to be in Groovy and not Greclipse. Could you use a specific revision instead of a range to confirm that Greclipse is fine as long as resolve is fine? |
I can look a little further into the Grab with range, but it appears to be a Groovy issue that is showing though in Greclipse. |
Our grapes/grab looks like this
Our folder structure looks like
-Project1
--SubProject1
---SourceMainClass (Includes a Grape/Grab)
---MiscFiles
--SubProject2
---SourceMainClass (Includes a Grape/Grab)
---MiscFiles
--SubProject3
---SourceMainClass ((Includes a Grape/Grab)
---MiscFiles
Our projects do build/run properly after they are built, but once in a while our "Building Workspace" process in eclipse takes an extremely long time. We have found that it will take seemingly longer per SubProject that we have as we defined subproject above. We've worked around this by doing one of two things.
Exclude the subprojects we're not working on in the buildPath section in eclipse. If we're only doing one grab statement everything is pretty speedy.
Remove grab statements during development as our .classpath as all of the references we need, but when we deploy we rely on the grab statements to pull in our dependencies (We do think we made a bad choice not going with a build.gradle per subproject, but this has been working for us so far)
Notes:
*We are running the latest snapshot and this happens on Mars and Neon
The text was updated successfully, but these errors were encountered: