you do want to keep in version control any portable setting files,
any file which has no absolute path in it.
- .classpath (if no absolute path used, which is possible with the use of ide variables, or user environment variables)
- ide settings (which is where i disagree strongly with the 'accepted' answer). those settings often includes static code analysis rules which are vitally important to enforce consistently for any user loading this project into his/her workspace.
- ide specific settings recommandations must be written in a big readme file (and versionned as well of course).
rule of thumb for me:
you must be able to load a project into a workspace and have in it everything you need to properly set it up in your ide and get going in minutes.
no additional documentation, wiki pages to read or what not.
load it up, set it up, go.
it seems like these project files can change over time as you work on a project so yes, i place them under version control.
yes. everything but build output.
we use intellij idea, and keep '.sample' versions of the project (.ipr) and module (.iml) files under version control.
somewhat bigger thing here is sharing and re-use than versioning, imho. but if you are going to share these configurations, what better place to put them than the repository, right next to everything else.
some advantages of shared & versioned project files:
- you can check out any tag/branch and start working on it quickly
- makes it easier for a new developer to first set up the development environment and get up to speed
- this better adheres to dry, which is always deeply satisfying. before this, all developers had to set these things up every now and then, essentially doing repeated work. of course everyone had their own little ways to avoid repeating themselves, but looking at the team as a whole, there was a lot of duplicated effort.
note that in idea these files contain configurations such as: what are the "source" and "test source" dirs; everything about external dependencies (where are library jars located, as well as related sources or javadocs); build options, etc. this is stuff that does not vary from developer to developer (i disagree with this quite strongly). idea stores more personal ide settings elsewhere, as well as any plugin configurations. (i don't know eclipse that well; this may or may not be quite different.)
i agree with this answer that says:
you must be able to load a project into a workspace and have in it everything you need to properly set it up in your ide and get going in minutes. [...] load it up, set it up, go.
and we have it like this, thanks to versioned project files.
yes, except for the .settings folder. committing the other files works well for us. there is a similar question here.
although i generally agree on the "do not version generated files" approach, we have problems with it and have to switch back.
note: i am also interested in vonc's answer, particularly about the "get eclipse up within minutes" point. but it is not decisive to us.
our context is eclipse+maven, using m2eclipse plug-in. we have a common development environment, with common directories as much as possible. but it happens sometimes that someone would try a plug-in, or change little things in the configuration, or import a second workspace for a different branch...
our problem is that the generation of .project is done when importing a project in eclipse, but is not updated in all cases later on. it's sad, and probably not permanent as the m2eclipse plug-in will improve, but it's true right now. so we end up having different configurations. what we had today was that: several natures were added to many projects on some machine, which then behaved much differently :-(
the only solution we see is to version the .project file (to avoid risks, we'll do the same for .classpath and .settings). that way, when one developer changes her pom, the local files get updated using m2eclipse, all of them get committed together, and other developers will see all changes.
note : in our case, we use relative file names, so we have no problem to share those files.
so, to answer your question, i say yes, commit those files.
i also liked:
- rich seller's answer
no, i'm a heavy maven user and use the q for eclipse plugin that creates and keeps .project and .classpath updated. for other things such as settings for plugins i usually mantain a readme or wiki-page about that.
also those i've worked with that prefer other ides just use the maven-plugins to generate the files needed to keep their ide (and themselves) happy.
this is all opinion, i suppose - but best practices over the years indicate that files specific to a given ide shouldn't be stored in source control, unless your entire organization is standardized on one ide and you never have any intent on switching.
either way, you definitely don't want user settings stored - and .project can contain settings that are really developer specific.
i recommend using something like maven or ant as a standardized build system. any developer can get a classpath configured in their ide in a few seconds.
no, because i only version control files that are needed to build the software. besides, individual developers may have their own project-specific settings.
i am torn between two options here.
on one hand, i think that everyone should be free to use the set of developemnt tools they are most productive with, as long as all source artifacts are stored in version control, and the build script (say ant or maven) ensures standards compliance by specifying exactly which jdk to use, which versions of which third party libraries to depend upon, running style checks (e.g. checkstyle) and running unit tests etc.
on the other hand, i think so many people use the same tools (e.g. eclipse) and often it is much better to have some things standardised at design time instead of build time - for example checkstyle is far more useful as an eclipse plugin than as an ant or maven task - that it is better to standardise on the set of development tools and a common set of plugins.
i worked on a project where everyone used exactly the same jdk, same version of maven, the same version of eclipse, the same set of eclipse plugins and the same configuration files (e.g. checkstyle profiles, code formatter rules etc.). all of these were kept in source control - .project, .classpath and everything in the .settings folder. it made life really easy during the initial phases of the project when people were continually tweaking the dependencies or the build process. it also helped immensely when adding new starters to the project.
on balance, i think that if there are not too many chances of a religious war, you should standardise on the basic set of develop tools and plugins and ensure version compliance in your build scripts (for example by explicitly specifying the java version).i don't think that there is much benefit to storing the jdk and the eclipse installation in source control. everything else that is not a derived artifact - including your project files, configuration and plugin preferences (particularly code formatter and style rules) - should go into source control.
p.s. if you use maven, there is an argument for saying that the .project and .classpath files are derived artifacts. this is only true if you generate them every time you do a build, and if you have never had to tweak them by hand (or inadvertently changed them by changing some preferences) after generating them from the pom
these are what i consider to be generated files, and as such i never place them under version control. they can be different from machine to machine and developer to developer, for instance when people have different eclipse plugins installed.
instead, i use a build tool (maven) that can generate initial versions of these files when you make a new checkout.
.project and .classpath files yes. we do not however keep our ide settings in version control. there are some plugins that do not do a good job of persisting settings and we found that some settings were not very portable from one dev machine to the next. so, we instead have a wiki page that highlights the steps required for a developer to setup their ide.
- Should I keep my project files under version control?
- Should I check-in IDE project files to version control system?
- I have just created small android project in Eclipse, which files I should add to version control?
- Project not under version control - Imported from EGit repo
- Creating a new root directory in an Eclipse project under version control
- Eclipse: how to list files not under SVN version control
- Difficulty creating a brand new Eclipse project under version control of existing Git repositories?
- How should I version control my JavaFx 8 project in git repository with eclipse?
- Which Eclipse files belong under version control?
- version control for one-man project using eclipse?
- Import Android Test Project into Eclipse from Version Control
- What files should be committed to github for an eclipse project
- Putting a project in Eclipse under source control
- Eclipse: how to keep project source files and ant build.xml seperate from eclipse workspace?
- How to change java version and web version on org.eclipse.wst.common.project.facet.core.xml under .settings dir of eclipse project
- Which files should go into source control in a Flex Builder project?
- Eclipse (java) web services, what files to version and how to properly pull the project to a new computer?
- Where to keep text files in Android project in eclipse
- How to version control an Android project on Github and use intellij and eclipse IDE by different team members?
- How do you commit ONLY files you've "added" to version control in subclipse?
- How should I add licence information to maven project and its source files
- Two main() in different source files under same project
- Adding the svn:ignore property on files that already are under control
- Eclipse Subversive new files automatically added to version control
- Eclipse: project version as a parameter in multiple files
- What files are unnecessary when exporting an Eclipse Workspace to a version control repository?
- What to put under Source Control in a Java Project
- Getting Latest Version for all files in a Project
- What are some Eclipse project files I should not include in my project repos?
More Query from same tag
- Maven project: The hierarchy of the type SpittrWebAppInitializer is inconsistent
- Mac - TFS - Eclipse Error : unable to instantiate class "com.microsoft.tfs.client.common.ui.views.TeamExplorerView
- How to install Flowable designer in Eclipse Kepler
- Could Mac and Windows work on the same projects via GIT?
- How to show private members and methods in attached android source in eclipse?
- Eclipse - limiting to-do only to certain files (or omit entire folders in project)
- Why the Android emu crashes?
- Access properties file in an executable jar
- Asynctask, dimensions expected after this token
- Eclipse + PyDev: use docstring for type checking (like PyCharm)
- Export Eclipse RCP Product -> "Unresolved requirement: Require-Bundle: org.eclipse.ui.views"
- Undefined references when linking gsl library in eclipse
- How to use an Ant script to start and stop Tomcat server?
- Create a simple Login page using jsp and session
- fail to configure the Android Beacon Library in Eclipse
- Where to import mongo-2.10.1 jar in REST Web Server
- Eclipse: How to get full filepath from error "Failed to load JNI shared library"?
- Eclipse(2019-09) crashes while running SWTBot tests in windows docker
- AWS toolkit install error
- Problems connecting to h2 database in wildfly
- Can Git-Flow and branch-per-issue workflow in JIRA work together?
- Log file is not being generated in log4j2 in spring boot application
- UnsatisfiedLinkError: Native Library sunmscapi.dll already loaded in another classloader
- JNI UnsatisfiedLinkError... signature discrepancy?
- java.lang.OutOfMemoryError: PermGen space in embeded jetty
- Building fail in Eclipse C/C++ but works well in commandline
- Eclipse RCP Platform Migration
- Different behavior on the way I launch the program
- Eclipse (Luna) Slowness