search

lightbend / service-locator-dns

This project is deprecated
Other
60 stars 20 forks source link

Support the Scaladsl for Lagom #13

Closed huntc closed 7 years ago

huntc commented 7 years ago

Introduces support for Lagom's Scala DSL.

Also refreshes dependencies for Lagom 1.3 and renames the Lagom libraries and packages in accordance with the conventions required for binary compatibility moving forward.

Fixes https://github.com/typesafehub/service-locator-dns/issues/8

Will be released as 2.0.0 given the breaking changes.

huntc commented 7 years ago

Yeah, but you wouldn't want to mix Lagom client 1.3.7 with, say Lagom server 1.3.5.

... but why not @tmoore? Are you implying that they won't be binary compatible?

TimMoore commented 7 years ago

Correct, we make no guarantees about binary compatibility of internal interfaces between different Lagom modules, only the public interface used by Lagom services. Mixing different versions of different Lagom modules into one classpath is not something we test, support, or expect to work.

huntc commented 7 years ago

@TimMoore

https://github.com/typesafehub/service-locator-dns/pull/13#issuecomment-324490572

...then we must ensure that internal APIs aren't necessary to implement things such as the ServiceLocator... I think that part of the issue here has been that we've needed to use internal APIs (which I believe you've addressed given the latest service locator).

TimMoore commented 7 years ago

Agreed. Regardless of that, I think it makes sense to declare the dependencies as "provided". Is there a drawback?

TimMoore commented 7 years ago

Here's a previous discussion for context https://github.com/typesafehub/conductr-lib/issues/127

@jroper's conclusion at the time was that the best solution is to have the Lagom sbt plugin enforce consistency. This is not yet implemented, and I'm not fully convinced that this is the best solution.

I'd like to understand why marking the dependency on Lagom as provided is not workable (for this project or for conductr-lib), as this seems to be the exact use case that "provided" scope was invented for. I think of compile vs. provided scope as being roughly aligned to the library vs. framework distinction. Do you want your artifact to pull the dependency in, or do you expect it to already be there?

huntc commented 7 years ago

@tmoore I think there's also an arg to be made for "my lib is verified to work with its dependencies at the stated coordinates". Perhaps the real issue here is with the semver assumptions made by dependency management tooling. Npm may have this right, where each lib had its own dependency graph ie transitive dependencies are not shared.

Perhaps there's also consideration of the scope of "internal" eg should play-json have direct dependencies on internally scoped types within play-core...

TimMoore commented 7 years ago

Agree, but we have to work with the tools we have. This is a sore point for me, and maybe a conversation best had over a beer 😄

Play JSON and Play core is a bit of a different issue, because Play JSON has a completely different lifecycle than Play core. It is part of an independent build and has its own versioning.

This is not true of the Lagom modules (at least right now): they are all part of one build and one version lifecycle. They are partitioned into separate modules mostly to allow downstream users to depend only on the parts that they need, but it is not allowed to mix and match different versions of different Lagom modules.

A more apt comparison would be between different core Play modules (e.g., play-java and play-server) or different Akka core modules (e.g., akka-actor and akka-stream). As far as I understand, you're not able to mix different versions of those, either. In fact, this is one reason why we can't easily allow users to mix different versions of different Lagom modules, as they might bring in different versions of those transitive dependencies.