Open eric-milles opened 5 years ago
What's the use-case for setting the .project
or .classpath
file read-only? IIUC that would mean any Core/JDT UI that stores information in those files would be useless.
If a project is stored in TFS source control, files are ready-only unless checked out for edit. And just in general, files can be marked read-only to prevent modification -- strange I have to state that explicitly.
When the Maven integration encounters read-only .classpath
or .project
that it wants to modify, user is prompted to make file(s) writeable. Buildship/Gradle just loops running the synchronization task over and over, spiking my CPU and making Eclipse unresponsive.
I haven't encountered this scenario before. The synchronization failure would make sense to me but the infinite looping is unexpected. I'll look into this.
I'm trying to reproduce this but setting the .project
and .classpath
file read-only doesn't trigger the infinite loop. I also tried making the entire project read-only and I got the same results. I do get however the dialog you mentioned.
If I accept the file permission change the synchronization succeeds. If not, the sync finishes with a failure, and no looping is kicking in.
Any idea, what could be different in your setup?
In my build.gradle
, I have the following:
plugins {
id 'groovy'
id 'eclipse'
}
ext {
guavaVersion = '27.0.1'
jUnitVersion = '4.12'
}
sourceCompatibility = 1.8
targetCompatibility = 1.8
repositories {
jcenter()
}
dependencies {
compile 'org.codehaus.groovy:groovy:2.4.16:indy'
compile "com.google.guava:guava:${guavaVersion}-jre",{
transitive = false
}
testCompile "junit:junit:$jUnitVersion"
}
compileGroovy {
groovyOptions.optimizationOptions.indy = true
}
eclipse {
classpath.file.whenMerged {
println '.classpath merged'
entries.findAll { entry ->
entry.class.name in [
'org.gradle.plugins.ide.eclipse.model.Library',
'org.gradle.plugins.ide.eclipse.model.SourceFolder'
]
}.each { entry ->
if (entry.entryAttributes['gradle_used_by_scope'] == 'test') {
entry.entryAttributes['test'] = 'true'
}
}
}
project.file.whenMerged {
println '.project merged'
}
jdt.file.whenMerged {
println '.settings/org.eclipse.jdt.core.prefs merged'
}
}
Also thanks for looking into this so quickly. :)
Still no 'luck' on my side. Can you do me just one more favor: please check out if installing Buildship 3.0.1 fixes the issue. There, we fixed some file locking issues which might affect this scenario too.
Buildship 3.0.1 gives different behavior. If .project
is locked, there is an error in the Error Log view, but the refresh task does complete and a new one is not scheduled. If .classpath
is locked, the prompt to make it writable is displayed.
Could the prompt be displayed for the .project
file as well?
The prompt for the .classpath
file comes from the platform (probably JDT).
I see the same problem without .project files being read-only, after upgrading from Photon with Buildship 2.2.1.v20180125-1441 to Eclipse 2018-12 with Buildship 3.0.0.v20181106-1441-m. Will try 3.0.1.v20181217-1543.
I had the same problem and upgrading to Buildship 3.0.1 fixed it. However in my case the issue did not originate from read-only .classpath or .project files.
When
build.gradle
is edited and saved with "Automatic Project Synchronization" preference enabled, if the.project
or.classpath
file is read-only the synchronization task repeats indefinitely.