I have a project structure like this:

My Project
  - Other Team's Project
     -Third Party Dependency

My Project requires Other Team's Project to function, and both My Project and Other Team's Project require Third Party Dependency to function. We are using a dependency management system to manage these.

From a design perspective, is it better to have My Project transitively rely on Third Party Dependency? Or is it better for both My Project and Other Team's Project to both explicitly declare that they use Third Party Dependency?

A few other things:

  • Both projects need to have the same version of Third Party Dependency.
  • It is not guaranteed that if Other Team's Project is updated that My Project will be tested to ensure that nothing breaks, because they are managed by different teams.

2 Answers 2


Imagine what happens if the other team refactors its project to do the same thing without using the third party library and they remove their dependency. Or they switch to another third party library to do the same thing. Will your code still work?

If it does your code only depends on the other project, if not your code depends on the third party library too.

Both projects need to have the same version of Third Party Dependency.

That's a strong indicator that your project directly depends on the third party library too.

  • In cases like Python where the application has uses for transitive dependencies it makes sense to declare the dependency outright and let the packaging doing its job to do dependency resolution. Python and tools like poetry, in particular, declare multiple version support and in that way enable clients to determine which version of the now named dependency to use.
    – Marc
    Dec 5, 2023 at 22:24

This is mostly opinion-based I think, but I'll put in my 2p anyway.

The way I've always done it is by asking myself, what's the minimum amount of knowledge my code needs to have to do what its supposed to do?

If my code only uses code from Other team's library, then I will only include Other team's library as a dependency.

If my code also uses code from Third-party library, then I will include it as well.

Let's say I had the following classes from My Library, Other Library, and Third-party Library (I'll use Java for the example code)

package mylibrary;

import otherlibrary.Bar;

public class Foo {

    public void doFoo() {
        Bar bar = new Bar();

In the Other Library

package otherlibrary;

import thirdparty.Baz;

public class Bar {

    public void doBar() {
        Baz baz = new Baz();

In the Third-party library

package thirdparty;

public class Baz {

    public void doBaz() {

Because my code in Foo only depends on code from otherlibrary, that's all I would include, because that's all I care about. I don't care how otherlibrary.Bar#doBar does whatever it does, I just want it to do it.

If however, we changed the otherlibrary.Bar#doBar to accept a Baz to do something with, like

public void doBar(Baz baz) {

I would then need to change mylibrary.Foo#doFoo to something like

public void doFoo() {
    Bar bar = new Bar();
    Baz baz = new Baz();


Because I am now interested in how Bar#doBar is going to do its thing, and my code needs to know about Baz to do what I want it to do, I need to be explicit about the libraries I include.

If my code must know about stuff within the thirdparty library, then I must include it as a dependency.

Although perhaps the author of Bar should hide away more of those details so I don't need to include the thirdparty library...

  • 3
    I'm all for this. But dependency hell is always a problem if, for example, I start with thirdyparty version 4 and otherlibrary needs version 3. What do you folks do about it? Jul 12, 2017 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.