In enterprise Java / .Net projects, does every developer have all the dependencies in their classpath?
In large scale Java / .Net Enterprise projects, each developer needs to have all components / libraries / dependencies in their classpath / local development environment for it to be built?
Or can they be split into smaller sections that can be built in isolation (so they don't need to reference all dependencies)?
In other words: if they want to run the entire application, they need all the components; but if they only run a subset of the application, they only need the corresponding subset of the components.
Are large corporate projects usually organized in the first or second way?
Possible organization - if you are working on a module of the whole project that is self-contained, but references other modules (in other words, leaf-node in the dependency tree).
Another organization is if you dynamically load the classes you use, you can create without any of them in your classpath. To run it, your classpath needs to access the ones you load (there might be many others that form different parts of the project that you don't load).
These are theoretical possibilities; but what is the standard practice for corporate projects, in ... well, in practice?
I extended this to include .NET because I think the same problems will occur there (DLL hell?)
source to share
There is a different answer to this question for each project. A few general points:
- "running a subset of an application" is often not possible because very few applications are modular enough that each part can run independently.
- You sometimes have an application core that is always required and modules built on that core that are more or less independent of each other.
- The big difference is usually not between having and missing all the components, but between using them as source code and having JAR files in them.
- In large applications, developers usually only have the parts they work on in the source code, and the rest are like JAR files.
- If you need runtime modulation (i.e. components are loaded and unloaded on demand at runtime) then for OSGi .
source to share
They may only need a subset to build and another subset to run their tests, but since all dependencies are smaller than Java projects that are smaller than trivial in size can very quickly become a tracking nightmare, Java developers have to love developed a love / hate relationship with their complex build systems like Maven that manage their development environment for them.
For projects that do not use such a system, it is usually easiest to include all this time. The trade-off is overly bloated development environments rather than wasting time tracking down missing dependencies.
source to share
A good project structure will ruin everything so you can run independent modules.
But in real life, most projects I've seen don't do this until someone gets tired and takes the initiative to break them.
If you are using a dependency management framework like Maven or Ivy correctly, you can store the compiled modules on the server and load those dependencies as needed.
You can also get away with a lot of mock objects and services to help break testing dependencies on other product components.
source to share
I certainly agree with the comments that it would be "nice" to separate things. But in practice this is very rare.
Assuming you have to work in an environment that hasn't been split, there is another organizational strategy, and this is what I saw. Since your question is about build and run dependencies, you don't seem to be talking about processes, but about classes and jars.
A simple solution for this is to have a full set of built-in, integrated (or test integration-related) dependencies on a shared server.
Developers then build, in their local environments, the parts of the system they run on using a classpath that references their development first and then the corresponding shared server.
source to share
Your question is not very clear, but I think the answer is that every class your application requires must be in the CLASSPATH or classloader with a ClassNotFoundException called.
This is true whether you are a solo developer or working on a larger distributed team.
In my experience, apps are packaged one way. If you only want a subset, you must package it as such.
If you mean test cases as standalone, they are usually not packaged with production code.
source to share
In my opinion, this is not about whether developers can work on a subset of the application, but rather manage the dependencies between the projects (think Eclipse projects) that make up the application. Often times, you may have a tree of such projects, where one or more projects may depend on other projects. In such cases, it is usually the role of the bottom-up / shared project to ensure that the top-down projects are not disrupted by upward changes to that project.
Think of it this way: let's say you have a project utils
where you put all the normal / utility functions for your application - it 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, a person working with utils
, must also have proja
and projb
in my development environment, since any change in the utils
will to break them. However, if you are only working with projb
, you may not need to enable proja
as you have no dependency on that project.
source to share