compatibility with sbt 1.4.7 and scala 2.12.13

[domizei385]

As suggested in #375 here is a PR for my changes.

[bpossolo]

will this work on Macs?
my coursier cache lives in ~/Library/Caches/Coursier/v1

[domizei385]

This is only really relevant while building and testing the plug-in prior to its release. of course if you are doing just that it will fail.

[bpossolo]

yah I figured it might be an issue because im on a Mac M1 and wanted to help diagnose the failing test

[bpossolo]

can you provide some guidance on how to reproduce the failed test?
I checked out your PR, then launched the sbt console and ran test

sbt:sbteclipse-plugin> test
[info] ScalaVersionSpec:
[info] ScalaVersion
[info] - should parse Scala version "2.12.0"
[info] - should parse Scala version "2.12.0-SNAPSHOT"
[info] - should parse Scala version "2.12.0-RC10"
[info] - should parse Scala version "2.12.0-M1"
[info] - should parse Scala version "2.12.0-51e77037f2adc4ffa7421aa36803a5874292b70d"
[info] - should fail to parse "2.12"
[info] Run completed in 72 milliseconds.
[info] Total number of tests run: 6
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 6, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 1 s, completed Feb 11, 2021, 4:39:16 PM

[domizei385]

It is actually the integration test that is failing. You have to run sbt scripted to start those, but they should give plenty of errors on your machine.

[bpossolo]

thanks. I see it now

[error] (scripted) Failed tests:
[error] 	sbteclipse/02-contents
[error] 	sbteclipse/03-sbt-dependency-withsources
[error] 	sbteclipse/04-dependency-options
[error] Total time: 55 s, completed Feb 11, 2021, 6:38:49 PM

[domizei385]

I have added the path mapping for macOS, so you should be left with less issues (assuming the path is correct :)

[bpossolo]

[error] (scripted) Failed tests:
[error] 	sbteclipse/02-contents
[error] Total time: 55 s, completed Feb 14, 2021, 9:53:47 AM

🌞

[bpossolo]

The only remaining failure appears to be due to a relative/absolute path difference

expected

<classpathentry kind="lib" path="./lib_managed/biz/aQute/bnd/biz.aQute.bndlib/3.4.0/biz.aQute.bndlib-3.4.0.jar" />

actual

<classpathentry path="/Users/benjamin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/biz/aQute/bnd/biz.aQute.bndlib/3.4.0/biz.aQute.bndlib-3.4.0.jar" kind="lib"/>

also the lib and path attributes are reversed... I'm not sure if its checking for exact string matches or just that they're semantically equivalent.

[bpossolo]

whatever is creating the Lib (EclipseClasspathEntry) objects is passing an absolute path into the constructor.

case class Lib(
  path: String,
  sourcePath: Option[String] = None,
  javadocPath: Option[String] = None
) extends EclipseClasspathEntry {
  override def toXml = {
    val classpathentry = sourcePath.foldLeft(<classpathentry kind="lib" path={ path }/>)((xml, sp) => {
      println("path:" + path)
      xml % Attribute("sourcepath", Text(sp), Null)
    })
  ...
}

console:

path:/Users/benjamin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/biz/aQute/bnd/biz.aQute.bndlib/3.4.0/biz.aQute.bndlib-3.4.0.jar

I can't tell where those EclipseClasspathEntry objects are being created.
also, this broken test seems unrelated to your changes...

edit: I see they're being created here: https://github.com/sbt/sbteclipse/blob/master/src/main/scala/com/typesafe/sbteclipse/core/Eclipse.scala

[normana400]

is this PR delaying the generation of the 6.0 release?

[bpossolo]

@normana400 this project isn't really maintained anymore (last activity was over 2 years ago).

[mkurz]

I am pretty sure I know were the problem is and just need to find some time to finally make sbteclipse work with latest sbt 1.4+.
Actually it's on my TODO list already.
Anyway, I just want to let you know, that if you want to financially support Play, you can do that now via https://opencollective.com/playframework - that would allow contributors like me to spend more time working on it. Thanks!

[benmccann]

I merged a bunch of scala-steward changes, so you don't need a lot of the changes to the project setup files like build.sbt anymore

It might be nice to break this PR into a few like refactoring out the method to get the artifact home directory. Upgrading first to sbt 1.3. And then upgrading to sbt 1.4

[benmccann]

was this statement wrong?

[benmccann]

let's not change this. I think it's handled by the release process and it will throw things off if it's manually changed

[mkurz]

@benmccann I can work on this soon, it's not difficult to fix. btw, are you still using Play?

[benmccann]

Hey, I'm not really using Play anymore. I got a new computer a year or two ago and I just started trying to get an old personal project that's using Play running on it and happened to notice there was a bit of a backlog here. I don't really have time to devote to this project, but figured I'd merge all the PRs since they were just easy library upgrades.

I just setup a CI to make it easier to merge PRs without worrying about breaking things. A few of them seemed to work on my computer, but not on the CI, so I had to revert a couple of the upgrades I just merged. I'd recommend rebasing this PR against master so that it runs against the CI before merging anything.

[mkurz]

Closing in favor of #402