“src / main / java”约定的优点是什么?

我注意到很多项目有以下结构:

  • 项目-A
    • 箱子
    • LIB
    • SRC
      • 主要
        • java的
          • RootLevelPackageClass.java

我目前使用以下约定(因为我的项目是100%的Java):

  • 项目-A
    • 箱子
    • LIB
    • SRC
      • RootLevelPackageClass.java

我目前没有使用Maven,但是想知道这是否是一个Maven约定或者是否有其他原因。 有人可以解释为什么现在第一个版本如此受欢迎,如果我应该采用这个新的约定呢?

克里斯

主要好处是将test目录作为src子目录,与目录结构相同:

  • 项目-A
    • 箱子
    • LIB
    • SRC
      • 主要
        • java的
          • RootLevelPackageClass.java
        • 资源
      • testing
        • java的
          • TestRootLevelPackageClass.java
        • 资源

RootLevelPackageClass所有包私有方法将是可见的,即从TestRootLevelPackageClass可testing。 由于testing代码也是源代码,所以应该在src目录下。

是的,这是Maven公约。

即使你的项目是100%的Java(就像Maven btw的典型例子),你通常会有资源文件(根据Maven约定转到src/main/resources ),或者是web应用程序,或者…所有这些轻松进入Maven系统。

如果您对当前的构build系统感到满意(不pipe它是什么),那么没有理由切换到Maven。 否则,或者如果开始一个新的项目,你可以评估你的select,包括Maven。

它是一个Maven约定。

Maven基于“公约”而不是“configuration”范式。 这意味着:如果你不遵循这个约定,你必须configuration源的位置。 这是恕我直言的主要好处。

其他人已经告诉你这是一个Maven约定,我要回答你的问题:

绝对没有。 当然,把代码片段分开来分开根文件夹是很有好处的,但通常你也可以用同样的方法实现

  • [根]
    • SRC
      • com.org.net
        • 你的class
    • testing
      • com.org.net
        • YourTest.class
    • LIB
    • 箱子
    • 资源

代替。 实际上,这是Maven所做的一件大事,实际上是非常错误的 :它想要将二进制内容添加到仅用于文本内容的源代码库中! 所有的二进制内容应该在源代码库之外进行pipe理,包括web应用程序中的图像以及其他内容。

但是好吧,让我们假设你已经决定生活在有点臭的Maven生态系统中。 那么你当然应该尽可能严格遵循Maven约定。

是的,这是一个maven惯例,但即使你不使用maven,也有使用它的好处:

  1. 新来的项目人员将会有更快的速度,因为这是一个“标准”
  2. 这个约定是灵活的,并且有一个非Java代码和其他你没有的东西的地方。 这是它受欢迎的原因之一,你可能会发现它比你自己提出的scheme更好
  3. 如果你想在某个时候移动到maven,那将很容易

虽然我不认为你应该切换,但是当开始一个新的项目时,真的没有理由不使用它 – 除非你在哲学上不同意它打破代码。