我对Clojure和Java相对较新。为什么lein项目中的lib文件夹没有添加到lein项目的git repo中？我认为将所有必要的罐子放在那里进行分布式开发会很方便。
答案 0 :(得分：4)
在Leiningen项目中，project.clj文件指示项目的依赖项，当你运行'lein deps'时，project.clj文件中列出的所有依赖项都将下载到lib /。因此，没有必要检查jar，因为project.clj与'lein deps'命令组合是另一个人重现同一个lib /所必需的。检查所有罐子是多余的，浪费空间。
此外，正如mblinn指出的那样，最好从为分发和更新依赖项而设计的工件存储库中提取jar，而不是在依赖项更新时不断更改和提交新的jar。当您的项目依赖于快照变化时，尤其如此;如果您检查了罐子，每次更新快照时都必须检查一个新罐子，但是如果您依靠'lein deps'从工件库中取出罐子，那么您将保持最新状态努力。但即使对于非快照jar，通过在project.clj中更改其版本然后运行'lein deps'来更新依赖项比在lib /中手动放置jar并检查它更容易，更快。
我希望上面的解释是可以访问的。如果没有，并且你不理解所讨论的一些概念，比如工件存储库或依赖项，请告诉我，我会解释。
答案 1 :(得分：4)
Git在存储二进制文件时非常糟糕。如果你签入你的罐子，然后必须在线下进行升级，很快你的存储库就会达到数百兆字节。
答案 2 :(得分：3)
自动依赖关系管理的一大优势是，您的库不存储在VCS中，以及版本控制时的所有细微含义。
由于leiningen内部使用maven artifact解析，您需要手动指定哪些工件存储库，以防在默认存储库中找不到所需的依赖关系，即maven central repository，clojure releases和clojars
E.g。如果罗马v1.0尚未部署在maven中心，但它可以在java.net project kenai repo上找到，你必须输入你的project.clj这些内容：
...
:dependencies [[rome/rome "1.0"] ...]
:repositories {"kenai" "http://download.java.net/maven/2/"}
...
答案 3 :(得分：2)
Leiningen或任何其他依赖管理工具的重点在于它为您管理您的依赖项。这些依赖项位于单独的工件存储库中，这些工具库比源控制系统更适合处理软件工件的公共版本。 Leiningen捎带Maven（一个填充的java构建/依赖管理工具）存储库系统;但是，也有Clojure特有的工件回购。
无论如何，重点是您在project.clj中声明了项目所具有的依赖项，并将project.clj文件检查到源代码管理中。其他开发人员检查出来并运行'lein deps'来降低这些依赖关系，瞧！