2012-07-02 34 views
5

首先,我从C#开始回到Java,所以,如果我的术语或哲学不太一致,请致歉。软件包与java中的项目分离

下面是背景:我们已经有越来越多的为网络编写的内部支持工具。他们在前端使用HTML5/AJAX /其他流行语,后端使用Java。这些工具利用了一个轻量级的内部框架,因此它们可以共享一个用于安全性和其他配置的管理界面。每个工具都由独立作者编写,我希望这种趋势能够继续下去,所以我希望让未来的作者能够轻松地在我们已经决定用于事物的第三方库上保持“标准化”像DI,单元测试,ORM等

我们的包命名目前看起来是这样的:

  • com.ourcompany.tools.framework
  • com.ourcompany.tools.apps.app1name
  • com.ourcompany.tools.apps.app2name

...等等。

所以这里是我的问题:应该将这些应用程序(和框架)中的每一个作为Maven安装程序,Eclipse等目的的单独项目处理?

随着时间的推移,我们可能会出现很多应用程序,所以看起来分离会让依赖关系更加清洁,并让其他人更轻松地使用单个工具。另一方面,(1)也许“分裂”一个包装结构的较深部分在多个项目中是一种代码异味,(2)将它们组合在一起会使工具编写者更倾向于使用已经存在的第三方库工具。

FWIW,我最初的直觉是将它们分开。

什么说你,Java大师?

回答

3

我把我的项目分离出来,但是使用父pom来包含所有的依赖和其他公共属性。各个工具/项目都有一个名称和一个对父项目的引用,以及任何项目特定的依赖关系(如果有的话)。这有助于保持常见的库和依赖关系,因为常见的库已经全部配置好了,但允许我专注于需要使用的代码库的特定部分。

+0

直到你提到它之前,我还没有意识到依赖关系处理的父pom概念。我真的很喜欢这个想法来加强整个应用程序的标准化。其他答案也很棒,但是父母给了这个优势。谢谢! –

7

我绝对将它们分开。为了Maven的目的,确保每个应用程序/项目对框架/应用程序都有适当的依赖关系,因此当您只想构建单个应用程序时,您不必构建所有应用程序。

1

如果某个项目的某个部分可能在多个项目中使用,则有必要将其解决。如果您需要更新其中一个常用项目中的代码,它会使它更简洁一些。

2

我肯定会把这些东西分成单独的项目。

你应该使用Maven来处理依赖/自动生成过程(无论是自己内部的共享库和第三方的依赖)。多个应用程序引用相同的共享库不会有任何问题 - 如果需要,甚至可以保留多个版本。

夫妇从这种做法奖金:

  • 这将迫使你仔细想一下你的API设计,为共享项目,这将是从长远来看是好事。
  • 这可能也给你有关源代码控制权的粒度 - 即你的开发人员可以检查出并在特定应用程序或后端模块单独工作
0

如果你把它们放在一起,你将有更少的障碍开发,构建和部署您的工具。

我们有相反的情况,有许多单独的项目。将它们合并成一个项目树后,我们的工作效率会更高,这对我们来说比任何惯例发生的趋势都重要。