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

Switch to scala 2.12 as build default #3132

Merged
merged 9 commits into from
Nov 26, 2019

Conversation

echeipesh
Copy link
Contributor

@echeipesh echeipesh commented Oct 21, 2019

Switching to scala 2.12 gives us 25% faster build time on this project and better compatibility with tools like metals. Developer time is precious so that's nothing to sneeze at.

There are couple of issues with this PR that are still outstanding

  • geowave version we're using is 0.9.3 and has a strict dependency on scala 2.11 dependencies
  • geomesa version has similar problem
  • publish scripts need to be adjusted
  • deprecation warnings need to be resolved

Overall the geowave and geomesa projects are being unlinked from the main build for a bit as those problems look like they'll be harder to solve and both of those projects are experimental and not in heavy use.

CQs required:

Fixes #3139

@pomadchin
Copy link
Member

pomadchin commented Oct 23, 2019

The build fails because of this lightbend-labs/mima#422 the workaround is

resolvers += Resolver.url(
  "typesafe sbt-plugins",
  url("https://dl.bintray.com/typesafe/sbt-plugins")
)(Resolver.ivyStylePatterns)

echeipesh and others added 8 commits November 21, 2019 13:42
- geomesa does not cross publish for 2.12
- geowave does not corss publish for 2.12

These projects are both experimental so they're bing unlinked from the build until we either update or figure out the best way to deal with them.
Two cases here:
- Type constraint was added for clarity but is actual constraint on the match
- We know the numerical domain of the match in internal API
move commonSettings to Settings
Use Def.settings
@pomadchin
Copy link
Member

I requested a PMC approval, but not sure would it be completed successfully or not, due to ongoing changes in the locationtech eclipse structure.

Copy link
Member

@pomadchin pomadchin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, added a couple of comments to discuss, but it is good to go as it is. Also all CQs were approved by Jim and awaiting the IP team review. Merging once all CQs are closed!

}

def monocle(module: String) = Def.setting {
"com.github.julien-truffaut" %% s"monocle-$module" % ver("1.5.1-cats", "2.0.0").value
Copy link
Member

@pomadchin pomadchin Nov 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think RasterFrames are using the syntax like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's where I lifted this approach but I've certainly seen it in other projects. What do you think? I'm in favor of collapsing the version numbers to here so there is a minimum amount of indirection in the build overall.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@@ -10,9 +10,7 @@
"project vectortile" test \
"project util" test \
"project gdal" test \
"project geowave" compile test:compile \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope we won't forget to remove the code from the codebase.

@@ -58,7 +58,7 @@ object EuclideanDistanceExamples {
val tileRDD: RDD[(SpatialKey, Tile)] = inputRDD.euclideanDistance(ld)

val maxDistance = tileRDD.map(_._2.findMinMaxDouble).collect.foldLeft(-1.0/0.0){ (max, minMax) => scala.math.max(max, minMax._2) }
val cm = ColorMap((0.0 to maxDistance by (maxDistance/512)).toArray, ColorRamps.BlueToRed)
val cm = ColorMap(Range.BigDecimal.inclusive(0.0, maxDistance, maxDistance/512).map(_.toDouble).toArray, ColorRamps.BlueToRed)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What a syntax!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oy ... I know. I get what they're saying with this deprecation but this is the least-worst alternative. I want to keep the number of warnings down so we don't go into auto-ignore warning mode and miss something that matters though.

@@ -66,6 +65,9 @@ object VoxelKey {
(k, sk) => VoxelKey(sk.col, sk.row, k.z)
)
}

implicit val voxelKeyEncoder: Encoder[VoxelKey] = deriveEncoder[VoxelKey]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, would the annotation here more user friendly? (less lines ~ easier to understand)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They didn't compile for some reason and this was the work-around. I didn't look into why they didn't because it seems like the annotation has been very fragile in other cases and using deriveEncoder is mostly the default in my mind.

@@ -94,7 +94,7 @@ object RDDHistogramMatching {
sourceHistograms: Seq[Histogram[T1]],
targetHistograms: Seq[Histogram[T2]]
): RDD[(K, MultibandTile)] =
rdd.map({ case (key, tile: MultibandTile) =>
rdd.map({ case (key, tile) =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need extra brackets here: rdd.map { case (key, tile) => (key, HistogramMatching(tile, sourceHistograms, targetHistograms)) }. This comment can be applied to all changes below btw.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going for minimum code change outside of configuration here, would rather not get sucked into format shuffling. Having said that once we get the guild and publishing sorted out we really should look into enforcing a code formatting standard for the library.

@@ -0,0 +1 @@
ThisBuild / version := "3.1.1-SNAPSHOT"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is keeping the version in a separate file more convenient? With my gt-contrib and gt-server experiences I didn't notice any real wins ):

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opening the discussion with this. Felt like I should pull this out of Version.scala which always stumps me. I'd be also OK with putting this version into build.sbt with other build settings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let’s try with a version in a file; but I’m just worrying that it would be just an extra file and the story would be the same as a Versions class in a separate file.

@pomadchin pomadchin merged commit 1d1561c into locationtech:master Nov 26, 2019
@echeipesh echeipesh mentioned this pull request Dec 18, 2019
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade Cats Ecosystem Dependencies
2 participants