donat
commented
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.
Open eric-milles opened 5 years ago
donat
commented
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.
eric-milles
commented
5 years ago 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.
eric-milles
commented
5 years ago 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.
donat
commented
5 years ago 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.
donat
commented
5 years ago 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?
eric-milles
commented
5 years ago 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. :)
donat
commented
5 years ago 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.
eric-milles
commented
5 years ago 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?
donat
commented
5 years ago The prompt for the .classpath file comes from the platform (probably JDT).
aleksandarsusnjar
commented
5 years ago 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.
haeuserd
commented
5 years ago 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.gradleis edited and saved with "Automatic Project Synchronization" preference enabled, if the.projector.classpathfile is read-only the synchronization task repeats indefinitely.