在大型Java / .Net Enterprise项目中，每个开发人员都需要在他们的类路径/本地开发环境中拥有所有组件/库/依赖项，为了建立它？
或者他们分成较小的部分可以隔离构建（这样他们就不需要引用所有依赖项）？
换句话说：如果他们想要运行整个应用程序，他们需要所有组件;但如果他们只运行应用程序的子集，他们只需要相应的组件子集。
大型企业项目通常是以第一种方式还是第二种方式组织的？
可能的组织是，如果您正在处理整个项目的模块，该模块是自包含的，但由其他模块引用（换句话说，依赖关系树中的叶节点）。
另一个组织是，如果您动态加载您使用的类，则可以在类路径中构建其中没有任何类。要运行它，您的类路径只需要访问您实际加载的那些（可能有许多其他组成项目的不同部分，您不加载）。
这些是理论上的可能性;但是，在实践中，企业项目的标准做法是什么？
我已将此扩展为包含.Net，因为我认为会出现同样的问题（DLL地狱？）
答案 0 :(得分：4)
对于每个项目，这个问题都有不同的答案。一些一般性观点：
答案 1 :(得分：2)
他们可能只需要一个子集来构建，另一个子集来运行他们的测试，但是因为所有不太重要的Java项目的依赖关系很快就会成为一个需要跟踪的噩梦，Java开发人员已经来爱与他们精心设计的构建系统（例如Maven）建立了爱/恨关系，这些构建系统为他们管理他们的开发环境。
对于不使用此类系统的项目，通常最简单的方法就是始终包含所有内容。权衡是不必要的膨胀开发环境，而不是花时间追踪缺失的依赖关系。
答案 2 :(得分：1)
一个好的项目结构会破坏事物，以便您可以运行独立的模块。
但在现实生活中，我见过的大多数项目都没有做到这一点，直到有人厌倦了并主动分解它们。
如果您正确使用Maven或Ivy等良好的依赖关系管理基础架构，则可以将已编译的模块存储在服务器上，并根据需要下载这些依赖关系。
您还可以使用许多模拟对象和服务来帮助分解对其他产品组件的测试依赖性。
答案 3 :(得分：1)
我当然同意这样的评论：将事情分开会很“好”。但在实践中，这是非常罕见的。
假设你必须在一个尚未分离的环境中工作，那就是另一种组织策略，这就是我所见过的。由于您的问题涉及构建和运行依赖关系，因此您似乎不是在谈论进程，而是关于类和jar。
简单的解决方案是在共享服务器上拥有完整的集成，集成测试（或集成测试就绪）依赖关系。
然后，开发人员在他们的本地环境中构建他们正在使用的系统部分，使用首先引用其开发的类路径，然后是相应的共享服务器。
答案 4 :(得分：0)
您的问题不是很清楚，但我认为答案是您的应用程序需要的每个类都必须在CLASSPATH或类加载器中抛出ClassNotFoundException。
无论您是独立开发人员还是在更大的分布式团队中工作，都是如此。
根据我的经验，应用程序是单向打包的。如果您只想要一个子集，则必须将其打包。
如果您将测试用例视为独立的，那么这些测试用例通常不会与生产代码打包在一起。
答案 5 :(得分：0)
在我看来，开发人员是否可以处理应用程序的一个子集，而不是管理组成应用程序的项目（想想Eclipse项目）之间的依赖关系。通常，您可能拥有一个这样的项目树，其中一个或多个项目可以依赖于其他项目。在这种情况下，通常是上游/共同项目的作用，以确保下游项目不会因上游项目的变化而中断。
这样想吧 - 让我们假设您有一个utils项目，您可以在其中放置应用程序的所有常用/实用功能 - 这可能是验证逻辑，字符串实用程序，日志记录等。您有一个一堆使用此utils中的类的其他项目。
utils
/ \
proja projb
在这种情况下，处理utils 的人 也有proja 和 < / strong> projb关于他们的开发环境，因为对utils的任何更改都会破坏它们。但是，如果您只使用projb，则可能不必包含proja，因为您不依赖于该项目。