1. 18 2月, 2015 1 次提交
  2. 08 2月, 2015 1 次提交
  3. 06 2月, 2015 5 次提交
  4. 05 2月, 2015 5 次提交
  5. 03 2月, 2015 1 次提交
  6. 02 2月, 2015 1 次提交
  7. 31 1月, 2015 1 次提交
  8. 29 1月, 2015 1 次提交
  9. 24 1月, 2015 2 次提交
  10. 22 1月, 2015 11 次提交
  11. 21 1月, 2015 2 次提交
  12. 16 1月, 2015 3 次提交
  13. 15 1月, 2015 2 次提交
    • C
      Merge Pull Request #1338 for Eclipse · 8bc0e535
      Carl Suster 提交于
      Fixes #1217.
      
      Once again ignore .classpath and .project in the Eclipse template. This has
      been requested in multiple PRs such as #1338 and #1221 and is essentially a
      reversion of #805. I copy the explanation for this change from the discussion
      in #1217 by @segfly:
      
      *In short*:
      
      I can't point to any counter-documentation off the top of my head. I just know
      from experience these files pollute a project's repo without adding value
      - that is, unless everyone contributing is using Eclipse and no-one is using
      dependency management. And even then, the guidance provided by the eclipse docs
      is bad advice.
      
      *In Long*:
      
      The .classpath file is used by Eclipse to maintain the project's classpath
      during automatic compile (every save of a file). In the olden days, one would
      manually configure the project within the Eclipse UI and include all the
      dependent jars necessary to compile your project. Eclipse then wrote that
      configuration out to the .classpath file.
      
      In theory, this file could be shared with others so they did not have to
      manually configure their eclipse classpath. In practice, I never saw it work
      out quite so well due to eventual bloating of the classpath with needless jars
      or jars that only existed on one person's machine. Mind you, many people back
      then also used to check their dependent jars into version control along with
      their source.
      
      Dependency management tools like Gradle and Maven have done away with all that
      of course. But they also integrate nicely with Eclipse and manage the project
      classpath dynamically. The .classpath file is basically rebuilt based on
      changes to the build.gradle file or pom.xml file. Effectively, this renders the
      whole point of checking in the .classpath moot as it is easily rebuilt by the
      Maven or Gradle plugin.
      
      The .project file is another animal completely. It basically describes what
      plugins should be applied to the project as configured in the Eclipse UI. Again
      the theory is it could be shared and creates a happy world. But due to
      different eclipse versions people may have, different plugins installed, etc.
      sharing the .project file actually causes more issues. And I've seen many
      projects unable to open due to a bad .project file - requiring one to delete it
      anyway (which then of course, when someone recreates it, they inevitably check
      it in over the old one and end up breaking someone else's environment).
      
      The bottom line is, regardless of what the eclipse documentation says, these
      are very much internal configuration files for eclipse and best left out of
      a repo.
      8bc0e535
    • C
      Merge pull request #1285 from paolofulgoni/gradle-wrapper · 1fea76a0
      Carl Suster 提交于
      Avoid ignoring Gradle wrapper jar file
      1fea76a0
  14. 14 1月, 2015 4 次提交