When commiting projects should I include .project & .classpath?

When I commit a web appliction to source control should I also include the .project & .classpath files ? I don’t think it should make any difference either way as other users who use the project should have the same project settings ?

  • Clearcase Vs Git version control
  • ClearCase - how to use like Git
  • What actually are tags in subversion (SVN)? And what tag tools does SVN offer built-in? (Compared to Clearcase)
  • SVN vs. ClearCase functionality
  • How to migrate Clearcase UCM/Base VOBs to Git(Stash) with full history?
  • What would be a good introdcutory tool to Clearcase?
  • Git for version controlling Android project
  • Working on GitLab/GitHub/BitBucket feature branch
  • Eclipse Git Error: Error occurred computing diffs
  • What is the significance of missing parameters on the 'git push' command?
  • Team Foundation Server Source Control Structure
  • Version control and test-driven development
  • 5 Solutions collect form web for “When commiting projects should I include .project & .classpath?”

    This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:

    1. Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.

    2. Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don’t want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.

    Choose the approach that makes the most sense for your team.

    For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.

    That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn’t necessarily contains said sources).

    In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.

    i would include them.

    The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.

    .classpath contain the classpath. it is needed if you use jar files.

    I would say that all files – including .project and .classpath – should go to source control, to ensure that everyone in the team has the exact same setup.

    Git Baby is a git and github fan, let's start git clone.