Play 2.4.0-RC3

[James Roper]

Hi all,

Play 2.4.0-RC3 has been released.  Play 2.4.0-RC3 has the following major changes since 2.4.0-RC2:

* Pulled api out of play-jdbc into jdbc-api artifact

* Pulled evolutions out of play-jdbc into evolutions artifact

* Renamed SbtEbean to PlayEbean

* A number of bug fixes

For a full list of changes see:

https://github.com/playframework/playframework/compare/2.4.0-RC2...2.4.0-RC3

Regards,

James

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Stuart Small]

Thanks for all the hard work!  I'm excited to try this out tonight.  Which version of play-slick should I use to match with Play 2.4.0-RC3?

[Rafael Trindade Chiappetta]

is there a deadline for 2.4 stable?

=====
Rafael Trindade Chiappetta

http://about.me/rafaeltc

@rafaeltscs

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mirco Dotta]

1.0.0-RC2

I noticed we have an issue with the pla-slick documentation that is being pulled into https://www.playframework.com/documentation/2.4.x/Home (it contains the old play-slick doc, not the new one).

Until it’s fixed, you can use the raw version https://github.com/playframework/play-slick/tree/master/docs/manual/working/scalaGuide/main/sql/slick ;-)

— Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[James Ward]

Please pin this post and unpin the old one.

On Thursday, May 14, 2015 at 7:35:11 PM UTC-6, James Roper wrote:

[Christian Kaps]

It seems that the complete documentation for Play 2.4.x is the old documentation. The documentation for 2.4.0-RC3 seems correct.

https://www.playframework.com/documentation/2.4.x/ScalaI18N

https://www.playframework.com/documentation/2.4.0-RC3/ScalaI18N

[Hossein Kazemi]

@Mirco: The doc points you to play-slick-evolution RC1 which doesn't seem to be published. I managed to find the RC2 though. Did you mean RC2 in the documentation?

Cheers

[Mirco Dotta]

Hi Hossein,

Using version 1.0.0-RC2 for both play-slick and play-slick-evolutions modules is the right way to go. I forgot to update the version in the doc, and in fact there is a PR for fixing exactly that https://github.com/playframework/play-slick/pull/253

Thanks for the due diligence! :-)

— Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

[Mirco Dotta]

By the way, the PR bumps all the versions to 1.0.0 because I would prefer to avoid having a version issue when we publish a Play 2.4 final release. I know it’s a bit confusing, but we are using the same strategy for other modules (e.g., play-ebean).

While I’m trying to keep the version up to date here https://github.com/playframework/play-slick/blob/master/README.md#current-version

— Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Mirco Dotta]

Hi Christian,

That’s right, there is an issue (and it’s not just play-slick). I’ve created a ticket https://github.com/playframework/playframework/issues/4473

Thanks for reporting the problem.

Cheers,

Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

[Hossein Kazemi]

@James, Docs for Scala Testing Spec2 are still using FakeRequest instead of RequestBuilder.

Cheers

[Mirco Dotta]

1 week without major issues or regressions reported against the latest RC will make it a final.

Cheers,
Mirco

[Hossein Kazemi]

Hi,

I am not able to use the H2-Browser from sbt anymore. Here is the error:

java.lang.ClassNotFoundException: org.h2.tools.Server

        at java.net.URLClassLoader$1.run(URLClassLoader.java:372)

        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(URLClassLoader.java:360)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

        at play.sbt.PlayCommands$$anonfun$6.apply(PlayCommands.scala:77)

        at play.sbt.PlayCommands$$anonfun$6.apply(PlayCommands.scala:74)

        at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:29)

        at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:29)

        at sbt.Command$.process(Command.scala:92)

        at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:98)

        at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:98)

        at sbt.State$$anon$1.process(State.scala:184)

        at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:98)

        at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:98)

        at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)

        at sbt.MainLoop$.next(MainLoop.scala:98)

        at sbt.MainLoop$.run(MainLoop.scala:91)

        at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:70)

        at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:65)

        at sbt.Using.apply(Using.scala:24)

        at sbt.MainLoop$.runWithNewLog(MainLoop.scala:65)

        at sbt.MainLoop$.runAndClearLast(MainLoop.scala:48)

        at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:32)

        at sbt.MainLoop$.runLogged(MainLoop.scala:24)

        at sbt.StandardMain$.runManaged(Main.scala:53)

        at sbt.xMain.run(Main.scala:28)

        at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)

        at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)

        at xsbt.boot.Launch$.run(Launch.scala:109)

        at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)

        at xsbt.boot.Launch$.launch(Launch.scala:117)

        at xsbt.boot.Launch$.apply(Launch.scala:18)

        at xsbt.boot.Boot$.runImpl(Boot.scala:41)

        at xsbt.boot.Boot$.main(Boot.scala:17)

        at xsbt.boot.Boot.main(Boot.scala)

[Mirco Dotta]

Hi Hossein,

A ClassNotFoundException usually indicates that the looked up class is not in the classpath, i.e., it looks like you may be missing the h2 library. Are you using the jdbc module (or any other play database access module)?

Also, is this an error that occurred while upgrading an existing Play project to Play 2.4? If so, what version of Play were you using before upgrading?

Cheers,

Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Hossein Kazemi]

Hi Mirco,

I was able to use this when my code was on RC1, this is happening in RC3 it seems. I went directly to RC3, Did not test RC2 though.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/GP2cSqeg_38/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[Mirco Dotta]

Hi Hossein,

If you are using play-slick there is a good explanation for why this work with Play 2.4.0-RC1 and play-slick 1.0.0-RC1, but it doesn’t work anymore with Play 2.4.0-RC3 and play-slick 1.0.0-RC2. The reason is that play-slick 1.0.0-RC1 used to depend on play-jdbc (which would automatically add dependency to several jdbc driver, h2 included), but that’s no longer the case in play-slick 1.0.0-RC2. Hence, the h2 dependency is no longer available and you will need to add it to your build.

Cheers,

Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Christian Schmitt]

 How could we configure logstatements with HikariCP?

And why do you so much changes in an RC?

[Mirco Dotta]

 How could we configure logstatements with HikariCP?

HikariCP doesn’t provide a way to log SQL statements. Instead, you should use the log capacities of your database vendor (source: https://github.com/brettwooldridge/HikariCP)

And why do you so much changes in an RC?

Because of https://github.com/playframework/play-slick/issues/245

Which was a serious issue preventing many users to actually use play-slick. The purpose of RCs is exactly to find out (and fix) serious issues/regressions. Furthermore, I wouldn’t call it a “big change” the fact that you need to add the database driver in your build (it’s not like you had to learn a whole new API...). That said, I can see this can cause confusion for users who have tried RC1 and are now moving to RC2, and I’m sorry for the trouble this change may have caused.

By the way, play-slick could actually bundle all the common jdbc drivers just like play-jdbc does. However, I’m not convinced it’s a good idea. Here are the tradeoffs I see:

Pros:

* No need to declare the JDBC driver in a project’s build.

Cons:

* Not needed JDBC libraries are being downloaded and bundled in each project (unless you manually exclude the ones you don’t need).

* No information about what version of a JDBC driver is being used by a project (the JDBC library version depends on the used play-slick version)/

* Moving a newer play-slick release may also cause the upgrade of the JDBC library (and that’s something I really don't like).

That’s why I’m of the idea that the current approach makes sense. Though, if you have a different opinion, I’d be really happy to hear it.

Cheers,

Mirco

[Grzegorz Slowikowski]

Hi

IMO play-jdbc shouldn't depend on H2 driver too. Why it does?

Regards

Grzegorz Slowikowski

--

[Mirco Dotta]

Actually, my statement about play-jdbc was incorrect, it only adds a dependency to H2 (not to all common JDBC libraries as I previously incorrectly stated). See https://github.com/playframework/playframework/blob/master/framework/project/Dependencies.scala#L41 And it also adds a test dependency to acolyte https://github.com/playframework/playframework/blob/master/framework/project/Dependencies.scala#L36

On why it does so, I can only speculate. However, changing it now I suppose would cause more troubles than benefits.

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Mirco Dotta]

Alright, looks like today I’m having a good time disproving myself.

Grzegorz, I absolutely agree with you that it would be good to remove the H2 dependency if there are no good technical reason for having it as a compile-time dependency. However, it turns out there is a good reason: Databases.inMemory relies on it, and that method is part of the play-jdbc API.

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Hossein Kazemi]

Hi Mirco, 

Thanks, It makes sense now. ;)

Cheers

[Anders Abrahamsen]

Quick question. We deploy play applications through nexus, and after Play 2.3 we had to add this line in the build.sbt to get the assets included:

packagedArtifacts += ((artifact in playPackageAssets).value -> playPackageAssets.value)

Is this still possible in 2.4, or does it have to be done in another way now?

[Stuart Small]

I'm having trouble getting evolutions to work.  I checked the docs and saw that they have been pulled out of jdbc.  I tried following the instructions but I think I'm missing a step since I'm still not seeing it try an evolution.  I even tried dropping the db and recreating it just in case it.

My dependencies from build.sbt:

libraryDependencies ++= Seq(
  evolutions,
  jdbc,
  "org.postgresql" % "postgresql" % "9.4-1201-jdbc41",
  "com.typesafe.play" %% "play-slick" % "1.0.0-RC2"
)

Is there anything I am missing?  Or any debug options I could turn on to get y'all more info?

On Thursday, May 14, 2015 at 7:35:11 PM UTC-6, James Roper wrote:

[Hossein Kazemi]

@Stuart: 

Remove jdbc and evolution from you dependencies and add:

"com.typesafe.play" %% "play-slick-evolutions" % "1.0.0-RC2"

Cheers

--

[Mirco Dotta]

Thanks Hossein :-)

By the way, documentation for enabling evolutions in play-slick is here https://playframework.com/documentation/2.4.0-RC3/PlaySlick#Support-for-Play-database-evolutions

And I’m working on improving the documentation to include the remarks you guys have raised in this thread. Thanks again!

— Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

You received this message because you are subscribed to the Google Groups "play-framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[Stuart Small]

The bit in the documentation that confused me was in the play 2.4.0-RC3 migration guide.  Under the header "Database evolutions support in a separate module" it says "Support for database evolutions used to be included with both Play JDBC and JPA support. That’s no longer the case. Therefore, if you are using evolutions, you now need to add an explicit dependency to evolutions in your project’s build" which I read to include evolutions under play-slick too.  I'm not entirely sure on when the module should or shouldn't be included otherwise I'd send a PR for docs myself.

Thanks for the help!

[Anders Abrahamsen]

I found the answer myself. The package name has changed.

Before I used

import play.PlayImport.PlayKeys._

Now I have to use

import play.sbt.PlayImport.PlayKeys._

[Mirco Dotta]

Hi Stuart,

I agree, thanks for pointing out what confused you. I’ve pushed a PR https://github.com/playframework/playframework/pull/4501

By the way, play-slick-evolutions is a tiny module (just needed to correctly wire play.api.db.DBApi to Slick), and it fully reuses the Play evolutions component. In fact, when declaring a dependency on play-slick-evolutions, the Play evolutions module is brought into your project as a transitive dependency.

Cheers,

Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Mirco Dotta]

Hi Anders,

Thanks for positing your finding, I’m sure it will be useful for others as well.

I had a look at the migration doc, and even though it’s not exactly visible, the information is actually there https://www.playframework.com/documentation/2.4.x/Migration24#Play-SBT-plugin-API. But I thought there is a better way to formulate it, so I’ve created https://github.com/playframework/playframework/pull/4502

Let me know if you think it’s helpful.

Cheers,

Mirco

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Christian Schmitt]

I'm still finding it wierd that you make so many changes in a RC, a RC should be for stability only, I mean between RC1 -> RC3 I mean before I could use Database.withInMemory, now in RC3 I need to use Databases.withInMemory, that is really aweful.

I thought you are doing some kind of semver, but an RC should never have breaking changes inside the API, which you did. Maybe its too early to call it RC, it's more like alpha.

Also its wierd that I can't use libraryDependencies += anorm while i can use libraryDependencies += evolutions, libraryDependencies += jdbc.. All are inside their own package but on anorm you let sbt fail:

[info] Loading project definition from /Users/schmitch/projects/envisia/loki-play/project

Anorm has been moved to an external module.

See https://playframework.com/documentation/2.4.x/Migration24 for details.

There is no reason for doing so...

[Anders Abrahamsen]

Looks good!

[Mirco Dotta]

Hi Christian,

See my comments below

I'm still finding it wierd that you make so many changes in a RC, a RC should be for stability only, I mean between RC1 -> RC3 I mean before I could use Database.withInMemory, now in RC3 I need to use Databases.withInMemory, that is really awful.

Database.withInMemory was not part of the 2.3.x API, which is why we decided it was ok to change the name of Database to Databases without deprecation. If Database would have been part of the Play 2.3.x API, then we would have done it as usual, i.e., by deprecating the old name and provide a pointer to the new one.

I thought you are doing some kind of semver, but an RC should never have breaking changes inside the API, which you did. Maybe its too early to call it RC, it's more like alpha.

My answer above should also clarify this point. Semantic versioning is indeed in place for final releases. RCs are not alpha, but code is not frozen, otherwise they wouldn’t be called RCs.

Also its wierd that I can't use libraryDependencies += anorm while i can use libraryDependencies += evolutions, libraryDependencies += jdbc.. All are inside their own package but on anorm you let sbt fail:

[info] Loading project definition from /Users/schmitch/projects/envisia/loki-play/project

Anorm has been moved to an external module.

See https://playframework.com/documentation/2.4.x/Migration24 for details.

There is no reason for doing so...

This is because anorm was moved out of the play core. That said, I understand you find the shortcut to declare the dependency to anorm useful, but I’d say there a greater benefits in having the anorm module outside of Play core. Specifically, anorm can have its own release cycle, independent of when Play releases happen.

Both evolutions and jdbc are still part of Play core, which is why we can offer the conveniency for declaring a dependency to these components. However, I would not be surprised if in a future release these components will also be moved outside of Play core, and hence causing similar troubles to the one you are experiencing.

Also, note that if you want to be resilient to these changes, just use the standard way of declaring a dependency in sbt. For example, instead of using evolutions, you could declare the dependency as follows

"com.typesafe.play" %% "play-jdbc-evolutions" % “2.4.0-RC5"

Hope it helps.

Cheers,

Mirco

[Mirco Dotta]

Great. Thanks again!

----------------

Mirco Dotta - @mircodotta

Typesafe – Build reactive apps!

[Mirco Dotta]

Hi Christian,

See my comments below

I'm still finding it wierd that you make so many changes in a RC, a RC should be for stability only, I mean between RC1 -> RC3 I mean before I could use Database.withInMemory, now in RC3 I need to use Databases.withInMemory, that is really awful.

Database.withInMemory was not part of the 2.3.x API, which is why we decided it was ok to change the name of Database to Databases without deprecation. If Database would have been part of the Play 2.3.x API, then we would have done it as usual, i.e., by deprecating the old name and provide a pointer to the new one.

By the way, I forgot to mention that we of course didn’t do the change just for the sake of changing. There was a good technical reason, and this PR https://github.com/playframework/playframework/pull/4380 provides the context.

[James Roper]

On 19 May 2015 at 20:07, Christian Schmitt <c.sc...@briefdomain.de> wrote:

I'm still finding it wierd that you make so many changes in a RC, a RC should be for stability only, I mean between RC1 -> RC3 I mean before I could use Database.withInMemory, now in RC3 I need to use Databases.withInMemory, that is really aweful.

I thought you are doing some kind of semver, but an RC should never have breaking changes inside the API, which you did. Maybe its too early to call it RC, it's more like alpha.

No, that's not the purpose for RCs, we release RCs in order to identify issues that we can't fix once the final is released because they would break backwards compatibility.  Otherwise, we may as well just release 2.4.0 final, and then address stability in subsequent minor releases - version numbers are cheap, different classes of versions, if they don't serve any special meaning, only add confusion. Release candidate means "We have no planned breaking changes for this, and this could be the final release, but we want people to test it so that if we need to do breaking changes, we can do them before we are locked in with our backwards compatibility guarantees in the final release".  So breaking changes between RCs should be expected.  If you need stability in APIs, then don't use the RCs.

We've been releasing milestones all along, but issues in the way that slick installed itself, which for some reason weren't picked up by the milestones due to flukes in classloader ordering, and probably because not that many people were testing our milestones, exposed some major issues in the way our database modules were exposed, requiring us to separate the implementation of the database APIs from the APIs themselves.  This also meant that utility methods couldn't be on the Database companion object, since companion objects must live in the same source file as the trait, but now the trait and object were in different projects, forcing us to rename the Database object to Databases.

 

Also its wierd that I can't use libraryDependencies += anorm while i can use libraryDependencies += evolutions, libraryDependencies += jdbc.. All are inside their own package but on anorm you let sbt fail:

[info] Loading project definition from /Users/schmitch/projects/envisia/loki-play/project

Anorm has been moved to an external module.

See https://playframework.com/documentation/2.4.x/Migration24 for details.

There is no reason for doing so...

anorm is a helper that used to be defined like this:

def anorm = "com.typeasfe.play" %% "anorm" % PlayVersion.current

This worked because anorm was part of Play, so the current version of anorm was equal to the current version of Play.  But now we've pulled it out into its own module - this means features added to anorm can be released faster than Play, instead of you having to wait a year before you can get these features.  It also means that anorms release cycle no longer matches Play, so we can no longer use PlayVersion.current as the version for anorm.  So what version do we use?  Play has no idea what the current version of anorm is, so it's simply not possible for us to implement the above helper method anymore, which is why we've removed it (or rather, replaced its implementation with a helpful error message explaining how to migrate to the new way of doing things).