In enterprise Java/.Net projects, does every developer have all dependencies in their classpath?

Question

On large-scale Java/.Net Enterprise projects, does every developer need to have all the components/libraries/dependencies in their classpath/local development environment, in order to make it build?

Or are they divided up into smaller sections can be built in isolation (so that they don't need to reference all the dependencies)?

---

In other words: if they want to run the whole application, they need all the components; but if they are only running a subset of the app, they'll only need the corresponding subset of components.

Are large enterprise projects usually organized in the first way or the second way?

---

A possible organization is if you are working on a module of the whole project that is self-contained, but referenced by other modules (in other words, a leaf-node in the dependency tree).

Another organization is if you dynamically load classes that you use, you can build without having any of them in your classpath. To run it, your classpath only needs to access the ones that you actually load (there might be many others that form different parts of the project, that you don't load).

These are theoretical possibilities; but what's standard practice for enterprise projects, in... well, in practice?

---

I've expanded this to include .Net, because I think the same issues would arise there (DLL hell?)

Answer 1

Your question isn't very clear, but I think the answer is that every class your application needs has to be in the CLASSPATH or the class loader with throw a ClassNotFoundException.

That's true whether you're a solo developer or working on a larger, distributed team.

In my experience, applications are packaged one way. If you only want a subset, you have to package it as such.

If you mean test cases as something separate, those usually aren't packaged with production code.

Answer 2

They may need only a subset to build, and another subset to run their tests, but because all dependencies of less-than-trivially-sized Java projects can very quickly become a nightmare to keep track of, Java developers have come to love developed a love/hate-relationship with their elaborate build systems, such as Maven, which manage their development environment for them.

For projects that do not use such a system, it is generally easiest to just include everything all the time. The trade-off is unnecessarily bloated development environments versus having to spend time to track down missing dependencies.

Answer 3

A good project structure will break down things so that you can run independent modules.

But in real life, most projects I've seen don't do this until someone gets fed up and takes initiative to break them down.

If you use a good dependency management infrastructure like Maven or Ivy properly, you can store compiled modules on a server and download these dependencies on an as-needed basis.

You can also get away with having many mock objects and services to help break down the testing dependencies on other product components.

Answer 4

There's a different answer to this question for every project out there. A few general points:

• "running a subset of the app" is often not possible, as very few apps are modular enough so that each part of them can actually run independantly.
• What you sometimes have is an app core that is always required, and modules built on that core that are more or less independant of each other.
• The big difference is usually not between having vs. not having all components, but between having them as source code vs. having them as JAR files.
• On large apps, developers typically have only the parts they're working on in source code and the rest as JAR files
• If you need runtime modularization (i.e. components are loaded and unloaded on demand at runtime), that's what OSGi is intended for.

Answer 5

I certainly agree with the comments that it would be "good" to separate things. But in practice, that's very rare.

Assuming that you must work in an environment which has not been separated, there's another organizational strategy, and it's what I've seen used. Since your question refers to both build and run dependencies, you don't appear to be talking about processes, but about classes and jars.

The simple solution for that is to have the complete set of built, integration-tested (or integration-test-ready, for that matter) dependencies up on a shared server.

Then developers build in their local environments the portions of the system on which they're working, using a classpath which references first their development and then the appropriate shared server.

Answer 6

In my opinion, it's not whether developers can work on a subset of the application, but rather managing the dependencies between the projects (think Eclipse projects) that make up the app. Often you might have a tree of such projects where one or more project can depend on other projects. In such cases it's usually the role of the upstream/common project to make sure downstream projects are not broken due to changes in this upstream project.

Think of it like this - let's assume you have a utils project where you put all the common/utility functionality for your application - this could be validation logic, string utilities, logging, etc. And you have a bunch of other projects that use classes from this utils.

    utils
   /     \
proja   projb

In this case, the person working on utils should also have proja and projb on their development environment as any change to utils will break them. However if you're only working on projb then you might not have to include proja as you have no dependency to that project.