WIP - DON'T MERGE: Provide dependencies #129
Conversation
Does not publish the following dependent dependencies anymore (all supported versions): - akka-cluster - akka-http-experimental - akka-http - play-ws - lagom-javadsl-client - lagom-scaladsl-client This is achieved by using the `provided` scope when adding the dependencies. Addresses typesafehub#127
|
@jroper @huntc This is the first try of solving #127. Unfortunately, the PR is not fully fixing the issue, see the section Problem description. I am out of ideas how to actually fix the issue with the Also note the section Other Findings. In case you want to reproduce it use current master of https://github.com/lagom/activator-lagom-java-chirper and change the Problem descriptionI've tried the following combinations of declaring the Lagom onlyWhen marking only the Lagom libraries and not the dependent Play and Akka libraries as provided: .. then the Lagom service throws the following error in regards to Akka HTTP when starting it in ConductR: Lagom + Akka - not PlayWhen marking only the Lagom, Akka HTTP and Akka Clustering libraries and not the dependent PlayWS library as provided: .. then the Lagom service throws the following error in regards to Lagom + Akka + PlayWhen marking all dependent Lagom libraries in conductr-lib as provided: .. then the Lagom service works! However, the Play service Other FindingsThe sbt project // compile with scalac option -Ylog-classpath |
|
Even when we find a solution with Note that this will not only affect Lagom services, but also Akka and Play apps. |
|
Why does the Lagom conductr-lib library depend on Akka HTTP? Shouldn't it just use play-ws? Another solution would be to build against the minimum Lagom version that you can, for Java that would be 1.0.0, for Scala, 1.3.0. Then, sbt will use semantic versioning to resolve the version that the user wants. Note however that won't work for Maven, but then Maven provides no sane predictability on version conflict resolution anyway. |
|
That would also mean that conductr-lib would also introduce versions that get evicted and therefore evicted warnings are displayed. Not ideal. |
|
I don't know why sbt should warn on eviction of a binary compatible release, does it really do that? We could potentially use version ranges - however in the past I've seen big problems caused by using version ranges in sbt. The alternative is that you have to maintain an artifact for every single Lagom 1.x release - our cadence for these releases is 4 months at the moment, that's 3 artifacts a year, and you need one for Scala and one for Java, so 6 artifacts. Is that really an ideal option? What's the point in us putting all this effort into maintaining binary compatibility if it can't be utilised? |
|
@eed3si9n Does sbt really not use semantic versioning when it does eviction warnings? We've committed to binary compatibility for all Lagom 1.x releases, so there should be no need to warn if 1.3.0 evicts 1.2.2. |
|
In regards to the sbt eviction warnings, I was getting my information from here: http://www.scala-sbt.org/0.13/docs/Library-Management.html#Eviction+warning It states:
So I assume that the eviction warnings are triggered whenever a library with a different major version is part of the classpath, e.g. 1.2.x and 1.3.x. |
|
@jroper When using Lagom 1.0.0 in lagom1-java-conductr-bundle-lib and when a Lagom project uses the version 1.2.2 then you can the following eviction warning in regards to Lagom: |
|
@jroper @huntc After further discussions with @huntc and the conversations in here and at #127 it is time to summarize the current findings and proposed solutions. Note also the below Intermediate solution that I'll work on today to fix our issue until we've figured out a final solution (one of the Possible Solutions section). Findings Possible Solutions
Intermediate solution We will create two sbt-conductr versions for now:
We will also document the versions in the Lagom documentation accordingly. |
That doesn't solve the problem - even if Lagom 1.3 were internally binary compatible with 1.2, that doesn't change the fact that if a user wants to use Lagom 1.2, they can't, because ConductR bundle lib is forcing them to upgrade (at least partially) to Lagom 1.3. |
|
Given that Lagom 1.x is binary compatible (public APIs) there shouldn't be any reason why a user wouldn't want to upgrade from 1.2.x to 1.3.x, so maybe the solution is to simply force them to upgrade. And if they don't want to, well, then they can just use an older version of ConductR bundle lib. |
When the version is cross published (ends with We can certainly improve the guessing if we can promise some rules for well known libraries. |
|
Closing this one out. #151 solidifies the strategy that we'll keep Lagom 1.3.x as our base, allowing the user to override as necessary. |
Does not publish the following dependent dependencies anymore (all supported versions):
This is achieved by using the
providedscope when adding the dependencies.Addresses #127