希望将程序作为框架分发,但担心依赖项的数量

那 似乎 就像很多依赖,但我不认为它是在现实中。当然,似乎没有多少免费的功能复制。大多数依赖项都在做一些你本来需要实现自己的事情。

对我来说,如果我想把它当作“轻量”来传递,这似乎太过分了。

也许你需要调整你的言辞。-)

说真的,如果这些依赖是必要的,那么您摆脱它们的唯一方法就是自己编写等价的功能(坏主意)或者删除相应的功能(可能是坏主意)。对你来说,哪一个更重要;轻量还是实用?

编辑

功能性是最终的关键。我可以有我自己的自定义实现,但我想它会充满错误。但是我想保持它的小,小,容易吸引人。

好吧,你清楚地了解这些问题。这是你的决定。(但不要忘记,虽然有些人被“膨胀”所耽误,但其他人却被许多功能所吸引。)

我想有个折中的办法。保留该功能,但使其成为可选的,并提供一些方法让人们可以将其配置为输入/输出。当然,缺点是这意味着您必须测试配置选项的多个排列,这会使您的用户的安装/配置更加复杂。

看起来确实挺多的。不管指定多个库的问题是什么,您都限制了用户的WRT。他们可以在项目中使用的第三方库与您指定的库相同。

你能指定实现不可知库吗?例如 commons-logging 将委托给覆盖下的现有日志框架。如果您的用户已经在使用log4j以外的东西,那么这将允许他们继续进行而不必切换。

其次,您的框架做的太多了吗?与其提供聊天实现,不如提供一个合适的API,这样客户机就可以插入自己的聊天/通知机制。这样,您的框架就变得更通用,(再次)您的客户机可以选择实现特性的内容/方式。丰富的客户端API将为您的用户提供更多的选项,并扩展框架的实用性。

我应该限制正在使用的框架的数量吗?

如果你真的在使用/需要它们,不是真的。如果你只使用1%,我会尽量避免重叠的库和添加一个库。

我应该如何分发它?一个用于其他程序的独立JAR和一个用于单个程序的大型组合JAR可以吗?

许多项目以zip/tar.gz发行版的形式分发。但是对于一个框架来说,将其作为maven工件提供是一个很大的优势(在这种情况下,使log4j和log4j绑定 optional )

这许多依赖关系正常吗?

首先,你没有那么多的依赖性。其次,IMO重用日志外观、持久性库、实用程序类等没有任何错误(不使用此类库并编写自己的代码来替换它们将是愚蠢的)。第三,大多数用户不在乎,尤其是当您正在交付 好的特点 (而不是花时间重新发明轮子,最终制造错误)。

项目的规模(即它完成了什么以及将在什么环境中使用它)将与人们评估项目的适合性时通常有多少依赖性和配置的易用性相平衡。

你还没有真正地暗示过你的项目要达到什么样的目标,所以很难说你是否有一个膨胀的堆栈。然而,对于一些相当有用的东西,我个人不会对这些罐子有任何问题。

唯一敲响警钟的是数据库层和JDBC驱动程序。如果您的项目是一个“框架”,那么我就看不到特定的JDBC驱动程序是如何适合模型的,而持久性通常并不完全适合框架的模型。

我觉得你很担心:)依赖性的数量是不相关的,它们的成熟度是相关的。如果你仅仅因为想保持低依赖性而放弃功能性/可用性/灵活性等,那对你(和你的客户)来说将是一种损失。