2

One git repository I’m working with contains 50+ eclipse projects, which are all generated in a working copy by ./gradlew eclipse (eclipse stuff is not under source control). When one switches between branches or commits, the set of these projects sometimes changes. Calling ./gradlew eclipse after git checkout works, but it only creates newly discovered projects.

The projects that no longer exist in a commit one have switched to become orphans – no longer needed .eclipse, .classpath and .settings remain in the directory tree. Because of this, Import existing projects wizard in Eclipse executes with errors and some dependencies in the workspace become corrupt as well.

I tried writing a gradle task that would remove all existing eclipse files and then recreate them using a standard eclipse task. Finally, I'd like to remove eclipse files in the root of the repo, so that the import wizard showed all projects with no need to tick Search for nested projects.

// /.gradlew eclipse does not remove old projects' eclipse files
// so there is a chance of importing a deleted project to eclipse after its removal.
// This creates name conflicts and failures in eclipse build.
// /.gradlew eclipsex fixes this issue

task deleteEclipseStuffInAllDirs(type: Delete) {
  delete fileTree(dir: '.' , include: '**/.project')
  delete fileTree(dir: '.' , include: '**/.classpath')
  delete fileTree(dir: '.' , include: '**/.settings/*') // could not find how to delete such dirs themselves
}

task deleteEclipseStuffInRootDir(type: Delete) {
  delete fileTree(dir: '.' , include: '.project')
  delete fileTree(dir: '.' , include: '.classpath')
  delete '.settings'
}
deleteEclipseStuffInRootDir.dependsOn(":eclipse")

task eclipsex() {
}
eclipsex.dependsOn(":deleteEclipseStuffInAllDirs")
eclipsex.dependsOn(":eclipse")
eclipsex.dependsOn(":deleteEclipseStuffInRootDir")

Despite me setting up all dependencies, eclipse command does not always get executed. How do I force it?

P.S: I know there exists ./gradlew cleanEclipse, but it does not delete orphan eclipse files for some reason.

UPD: Console output:

$ ./gradlew eclipse
Starting a new Gradle Daemon for this build (subsequent builds will be faster).
Parallel execution with configuration on demand is an incubating feature.
:eclipseClasspath
:back-end:proj1:eclipseClasspath
:back-end:proj2:eclipseClasspath
:back-end:proj3:eclipseClasspath
...
:front-end:proj42:eclipseJdt
:front-end:proj42:eclipseProject
:front-end:proj42:eclipse

BUILD SUCCESSFUL

Total time: 13.677 secs

 

$ ./gradlew eclipsex
Parallel execution with configuration on demand is an incubating feature.
:deleteEclipseStuffInAllDirs
:eclipseClasspath
:eclipseJdt
:eclipseProject
:eclipse
:deleteEclipseStuffInRootDir
:eclipsex

BUILD SUCCESSFUL

Total time: 3.788 secs
Alexander Kachkaev
  • 842
  • 15
  • 29
  • It seems like it is generally a bad idea to check in eclipse files into source control: http://stackoverflow.com/questions/337304/which-eclipse-files-belong-under-version-control – RaGe Feb 29 '16 at 12:35
  • All eclipse files are in .gitignore, that's the thing. I need to generate them every time after switching between branches, and the problem is that the ones that are not applicable in the just-checked-out version remain in the filesystem. I want to have a command to remove them all and then re-create with gradle. – Alexander Kachkaev Feb 29 '16 at 12:39
  • 1
    The way you're declared your task dependencies, it is possible for eclipse to run before delete, which would delete the any files generated by eclipse task. From your description it sounds like delete needs to run first. Why not add an additional `dependsOn` or a `mustRunAfter` ? – RaGe Feb 29 '16 at 12:40
  • The order seems to be correct (as long as I understand it). The problem is that `eclipse` does not do what it should when I call `eclipsex`. It is shown in the list of the involved builds though. My guess is that `eclipse` is somehow skipped because gradle thinks that this task does not need to be run. (i.e. it's ready) – Alexander Kachkaev Feb 29 '16 at 12:44
  • @RaGe I updated the question with the console output. – Alexander Kachkaev Feb 29 '16 at 12:52
  • @RaGe any chance to call the task from the plugin task? Something like tasks.eclipseClasspath.dependsOn(eclipsex) – ps23 Feb 29 '16 at 20:42
  • @PatrickS yes you can. As soon as task eclipseClasspath is added to the taskgraph, you can do add dependsOn to it. To guarantee that the task is available in the taskgraph, it might help to stick this line in an `AfterEvaluate{}` block. – RaGe Feb 29 '16 at 21:13
  • @AlexanderKachkaev I feel like configuration on demand is at fault here. Are you explicitly enabling config on demand with the command line flag or through a setting in gradle.properties? – RaGe Feb 29 '16 at 21:26

0 Answers0