Fixes #208 - Support sbt 1.4.x+

[jmswenski]

sbt 1.4.x introduces a breaking changes to how plugins can hook
into the compiler as well as some API changes for stamping files
so that the incremental compiler can recognize modifications

This pull requests updates sbt-play-ebean to account for those
changes with respect to ebean enhancement.

[felipebonezi]

@jmswenski there's some conflicts and travis isn't building! :-(

[jmswenski]

@felipebonezi - all fixed up. I'm kinda curious about this one though, if we merge this and include it in 6.1.0, that means 6.1.0 won't work for people using < 1.4.x since there is some breaking API changes in 1.4.x for Files and VirtualFile's and File hashes.

@octonato - Could you point me what the preferred solution for play plugins, I know we can support sbt 0.13 and sbt 1.x at the same time in the same project. Is there a way to support {0.13, 1.3, 1.4+} or is it just that we should say the next release of this plugin uses sbt 1.4 and its not possible to use sbt 1.3 or earlier

[felipebonezi]

I think it would be better to use another release because 6.1.0 has some improvements that works for sbt 1.3

So, I guess it would be better to release 6.2.0 or even 7.0.0

[codecov-commenter]

Codecov Report

Merging #219 (f77b1a5) into master (36c6f65) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #219   +/-   ##
=======================================
  Coverage   13.66%   13.66%           
=======================================
  Files           7        7           
  Lines         139      139           
  Branches       10       10           
=======================================
  Hits           19       19           
  Misses        120      120           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 36c6f65...f77b1a5. Read the comment docs.

[octonato]

Sorry @jmswenski, I missed the notification from your last question.

I don't remember if we have ever had project that was supporting sbt 0.13 and 1.x at the same time. Probably in the beginning when we were transitioning to 1.x, but I don't know what was the trick to make it happen.

If I may suggest something, don't take that path. Maintaining an open source project is very demanding and there are certainly other things that you may want to improve in the project that are more important then supporting sbt 0.13. It's quite old version and at some point people need to upgrade their stack.

At some point, the maintainers need to draw a line and users need to understand that it's the maintainers' free time that are sacrificed.

Upgrading the stack of an application is costly, but who has to pay that price? The maintainers by keeping supporting old versions (for free) or the developers/companies that need to invest in renewing the stack?

Note that if someone really needs to stay with sbt 0.13, they can always pick an old version. And if they need a bug fix, they can provide the fix or backport it. They can also fork the project and keep going.

[felipebonezi]

@octonato can you check why "TravisCI - Branch" is broken?
I think it wouldn't publish to Sonatype at this step in Pull Request.

[octonato]

@felipebonezi, seems to be the same issue as here: playframework/play-json#612. I didn't look in detail though and will probably not have time in the next two weeks.

Anyway, once we investigate and fix it in play-json, we will need to apply the same here.

@marcospereira, in case you pick playframework/play-json#612, can you report here what needs to be done?

[octonato]

@felipebonezi, my last response was incomplete and I realise it now.

So, first, we have the fix for the release.

The error is happening because sonatype plugin automatically pick the groupId for the profile name, but the write profile to use is: com.typesafe

2021-06-03 19:58:31.475Z error [Sonatype] [MISSING_PROFILE] Profile com.typesafe.play is not found. Check your sonatypeProfileName setting in build.sbt  - (Sonatype.scala:425)

Previously, this was automatically set by the interplay plugin, but this project is probably not using it anymore. So it needs to set the profile name to com.typesafe explicitly. See this PR in play-json: playframework/play-json#642

To answer your question about the job being run in a PR, that's indeed not normal. But I think this is happening because the PR comes from a branch in this repo and the branch do have a tag.

[bion]

Is this PR just waiting on the fix in #217 ?

[bion]

Hello, I'm curious if this is ready to merge now that the Sonatype issue appears to be resolved. It would be nice to be able to use a newer version of sbt that doesn't rely on a vulnerable version of log4j.

[PromanSEW]

@mkurz please look and approve. Thanks

[octonato]

LGTM

[octonato]

Approved, but build is still failing with

2021-06-03 19:58:31.475Z error [Sonatype] [MISSING_PROFILE] Profile com.typesafe.play is not found. Check your sonatypeProfileName setting in build.sbt  -

I think this is happening because this repo is still configured to use the Lightbend credentials and those credentials can't publish to com.typesafe.play.

I will merge as is, but it means that we won't have a published snapshot. The next step here will be to move to GH Actions. The right credentials are not configured in GH, so if we move to GH Actions, we it will work out of the box.

[mkurz]

play-ebean 6.2.0-RC4 released, please have a look at the release notes how to upgrade: https://github.com/playframework/play-ebean/releases/tag/6.2.0-RC4. Please test and let us know if it works for you, thanks!