Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBT publish includes non-transitive evicted dependencies in POM #4662

Closed
1 task done
Woodz opened this issue May 10, 2019 · 2 comments
Closed
1 task done

SBT publish includes non-transitive evicted dependencies in POM #4662

Woodz opened this issue May 10, 2019 · 2 comments
Labels
area/library_management library management

Comments

@Woodz
Copy link

Woodz commented May 10, 2019

steps

Create a new project with two dependencies, one of which has a transitive dependency that evicts the other dependency, e.g.

  "org.optaplanner" % "optaplanner-core" % "7.20.0.Final",
  "com.thoughtworks.xstream" % "xstream" % "1.4.7"

(optaplanner-core has a dependency on xstream 1.4.10)

problem

POM file includes evicted dependency ("com.thoughtworks.xstream" % "xstream" % "1.4.7" in this scenario)

expectation

POM file does not include dependency as it has been evicted

notes

sbt version: 1.2.8

@eed3si9n eed3si9n added the area/library_management library management label May 10, 2019
@eed3si9n
Copy link
Member

In Maven semantics the nearest wins, so your direct dependency will win once someone uses it out of Maven Central.

@Woodz
Copy link
Author

Woodz commented May 10, 2019

In Maven semantics the nearest wins, so your direct dependency will win once someone uses it out of Maven Central.

Yes @eed3si9n , that is the behaviour that we are observing. However, this means that the behaviour of the packaged library (using nearest wins) is inconsistent with the behaviour within the library (using a specified conflict approach, where the default approach is that the latest version wins). This inconsistency means that eviction warnings actually are far more severe when packaging a library and this non-intuitive behaviour makes SBT harder to use and understand. Do you agree that there is a benefit to applying the same version conflict approach between update and publish and if so, which would you recommend changing?

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/library_management library management
Projects
None yet
Development

No branches or pull requests

2 participants