search

typesafehub / conductr-lib

Other
8 stars 13 forks source link

Provided Lagom 1.3 support #121

Closed jroper closed 7 years ago

jroper commented 7 years ago

This includes support for the new scaladsl. Included in this work:

No attempt has been made to maintain binary compatibility in the javadsl conductr bundle lib artifact. This is because it is actually an entirely new artifact, it has a new name, and the classes are in a new package, and so there can be no binary compatibility issues if both are loaded.

huntc commented 7 years ago

Thanks for doing this.

Is there no way that we can seek a binary compatible approach with what we have? There are downstream things that change otherwise (including sbt-conductr).

jroper commented 7 years ago

There's a number of things we can do - it depends on the goals.

We could avoid renaming the java project, so then the name of the Java project will be lagom1-conductr-bundle-lib, while the Scala project will be lagom1-scaladsl-conductr-bundle-lib, and likewise not change the package names so the Java one will use com.typesafe.conductr.bundlelib.lagom while the Scala one will use com.typesafe.conductr.bundlelib.lagom.scaladsl, and live with the slightly odd asymmetry where the Java API is not namespaced but the Scala API is. We could copy the Java project so that we have three, lagom1-conductr-bundle-lib and lagom1-javadsl-conductr-bundle-lib, which will essentially be the same but different artifact/package names, and lagom1-scaladsl-conductr-bundle-lib for Scala, and just live with the duplication. We could also have a lagom1-conductr-bundle-lib that is an empty library that simply depends on lagom1-javadsl-conductr-bundle-lib, this will technically break binary compatibility, but maintain compatibility with sbt-conductr.

Also, note that sbt-conductr will need to be changed anyway to support LagomScala.

jroper commented 7 years ago

@ygree You may be interested in this.

jroper commented 7 years ago

@huntc This is now ready for review. See my above comment for the pros/cons of breaking/maintaining compatibility. The important thing to note is that since both the artifactId and the package name is changing, the two different libraries can actually happily coexist on the classpath without causing any binary compatibility issues - thus avoiding the biggest problems associated with breaking binary compatibility.

jroper commented 7 years ago

The Java lib is still backwards compatible with 1.2, and 1.1 and 1.0. Though - it may try to force the upgrade of the Lagom libraries when it shouldn't. Not sure what the best way to deal with that is.

jroper commented 7 years ago

Hi @huntc, I've updated the artifact/sbt project names as requested, this should be ready to be merged now.

huntc commented 7 years ago

Thanks @jroper - LGTM - I'm getting @longshorej to review also so that he can become familiar with it.

Jason: please review/merge accordingly and then endure the pain of releasing to Sonatype. :-)

huntc commented 7 years ago

@jroper Is https://github.com/lagom/lagom/pull/448 required to be merged prior to this?

jroper commented 7 years ago

No, that has no impact on this, that only impacts api-tools, which is something sbt-conductr uses.