JDK-8198795 : Remove IDE specific files from the source code repository
  • Type: Task
  • Component: javafx
  • Sub-Component: build
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2018-02-27
  • Updated: 2019-05-06
  • Resolved: 2019-05-06
Related Reports
Duplicate :  
JDK-8223373 - Remove IntelliJ IDEA specific files from the source code repository
Duplicate :  
JDK-8223375 - Remove Netbeans specific files from the source code repository
Duplicate :  
JDK-8223374 - Remove Eclipse specific files from the source code repository
Description
Support for Gradle is pretty advanced in most modern IDEs, which means they can import the modules based just on Gradle project definition. So I propose to remove IDE specific files from the repo. This is the best practice anyway.
Comments
This issue was split into three separate issues, one for each IDE, so closing this as a duplicate.
06-05-2019
Yeah, I don't think that's going to be any better, but go ahead and try. The reason is that you would need to tell Gradle to generate the classpath files with some precise CLI module options and I highly doubt it will know how to do it automatically considering some of these issues are not yet resolved in Eclipse. And in any case, if you're doing that, it's just an extra step over keeping these files in the repo in my opinion.
28-02-2018
That is pretty standard with Gradle support for Eclipse. You would import the Gradle project into Eclipse and it will recreate Eclipse project configuration. Here is more info about it http://www.vogella.com/tutorials/EclipseGradle/article.html.. check out the part which explains how to import existing Gradle project
28-02-2018
Yeah, I probably don't understand. If I now remove all .classpath and .project files from the repo, how will Eclipse recreate them by itself?
28-02-2018
@nlisker I don't think you understood the nature of this request. I proposed to remove those files because IDEs are capable of recreating them. Obviously we have to test each one. But there is no sense to keep those files in the repo. IN some cases it is dangerous as their format changes through the years ( I remember Eclipse having trouble with old .projects files as some point) So you still can use your IDE the same way you use it now - nothing should change from that perspective
28-02-2018
I object. Eclipse with its ECJ compiler is much faster than Gradle because of its incremental compilation. Its integration of JUnit is also much easier than running Gradle tasks. There are other advantages as well. Maybe for Javac-only IDEs this makes sense (only NetBeans I think).
28-02-2018
As long as each IDE can work well from the gradle file, then this might be fine (would need to be tested). I know that it wasn't the case when we initially checked in the files. We would want to make sure that users of a particular IDE were happy with that IDE's gradle support before removing the checked-in IDE files. I note that we the files for the different IDEs could be removed at different times.
27-02-2018