Introducing Play 2.3.0

18,275 views
Skip to first unread message

James Roper

unread,
May 30, 2014, 7:25:44 PM5/30/14
to play-framework
The Play team is pleased to announce the release of Play 2.3.0!


What’s new in Play 2.3


  1. Introducing the activator command. You can use activator exactly like you would use play, but Activator brings new features too. (More about the Activator change.)

  2. Better tooling for static assets. Play now uses sbt-web which gives faster asset processing, more features, and better extensibility.

  3. Support for Java 8 (and continued support for Java 6 and 7).

  4. Better Java performance. Simple Java controllers give 40–90% better throughput. (Thanks to YourKit for sponsoring licenses.)

  5. Support for Scala 2.11 (and continued support for Scala 2.10).

  6. Anorm enhancements: SQL string interpolation, multi-value parameters, new types, and more.

  7. Web Services enhancements: separate client, SSL configuration, and more.

  8. Play templates have become Twirl templates: separate project, new sbt plugin, still excellent integration with Play

  9. Actors for WebSockets

  10. Custom SSLEngine for HTTPS

  11. Asset performance: faster serving, better caching.

  12. One Result to rule them all: all the result types which were deprecated in 2.2 are now gone and only Result remains.

  13. Lots of bug fixes. :)


For details see the Play 2.3 Highlights and the Play 2.3 Migration Guide.


Download Play 2.3


Play is now distributed through Activator.  Visit the Play downloads page for information on how to download and install Activator, and get started with Play.


We would like in particular to thank the community for the many contributions made.  A bit of git number crunching tells us that 168 unique contributors were involved in Play 2.3.x, and 132 of those had not contributed to Play before.  This brings us to an all time total of 365 unique contributors to Play!


Thanks,

The Play Team

--
James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

Mateusz Szczap

unread,
May 30, 2014, 8:30:55 PM5/30/14
to play-fr...@googlegroups.com
This is excellent news, thank you for your hard work!

Andy Czerwonka

unread,
May 30, 2014, 10:00:14 PM5/30/14
to play-fr...@googlegroups.com
Fantastic! Can't wait to upgrade.

Korrawit Yindeeyoungyeon

unread,
May 30, 2014, 11:18:15 PM5/30/14
to play-fr...@googlegroups.com
Awesome ! 
Big Thanks Play Team :)


On Sat, May 31, 2014 at 9:00 AM, Andy Czerwonka <andy.cz...@gmail.com> wrote:
Fantastic! Can't wait to upgrade.

--
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.

neverminder

unread,
May 31, 2014, 5:20:05 AM5/31/14
to play-fr...@googlegroups.com
Shouldn't this thread be pinned instead of the RC2 one?

Julien Richard-Foy

unread,
May 31, 2014, 5:21:11 AM5/31/14
to play-fr...@googlegroups.com
Hi, I think this part of the documentation is not accurate:
https://github.com/playframework/playframework/blob/master/documentation/manual/Migration23.md#npm
npm artifacts are not put in a lib/ directory.

Loic

unread,
May 31, 2014, 6:52:48 AM5/31/14
to play-fr...@googlegroups.com
Great job!

Martin Grotzke

unread,
May 31, 2014, 7:32:41 AM5/31/14
to play-fr...@googlegroups.com

Awesome, thanks for your great work!

--

juan....@reduc.edu.cu

unread,
May 31, 2014, 8:40:10 PM5/31/14
to play-fr...@googlegroups.com
Thanks a lot, specially for the Java improvements. This gets better every
day.

El Vie, 30 de Mayo de 2014, 8:30 pm, Mateusz Szczap escribió:
> This is excellent news, thank you for your hard work!
>
>
> On Saturday, May 31, 2014 1:25:44 AM UTC+2, James Roper wrote:
>
>>
>> The Play team is pleased to announce the release of Play 2.3.0!
>>
>>
>>
>> What’s new in Play 2.3
>>
>>
>>
>> 1.
>>
>>
>> Introducing the activator command. You can use activator exactly like
>> you would use play, but Activator brings new features too. (More about
>> the Activator change.
>> <http://www.playframework.com/documentation/2.3.x/Highlights23>)
>> 2.
>>
>>
>> Better tooling for static assets. Play now uses sbt-web
>> <https://github.com/sbt/sbt-web> which gives faster asset processing,
>> more features, and better extensibility. 3.
>>
>>
>> Support for Java 8
>> <http://www.oracle.com/technetwork/java/javase/overview/java8-2100321.ht
>> ml> (and continued support for Java 6 and 7).
>> 4.
>>
>>
>> Better Java performance. Simple Java controllers give 40–90% better
>> throughput. (Thanks to YourKit <http://yourkit.com/> for sponsoring
>> licenses.) 5.
>>
>>
>> Support for Scala 2.11 <http://docs.scala-lang.org/scala/2.11/> (and
>> continued support for Scala 2.10). 6.
>>
>>
>> Anorm enhancements: SQL string interpolation, multi-value parameters,
>> new types, and more. 7.
>>
>>
>> Web Services enhancements: separate client, SSL configuration, and
>> more. 8.
>>
>>
>> Play templates have become Twirl templates
>> <https://github.com/playframework/twirl>: separate project, new sbt
>> plugin, still excellent integration with Play 9.
>>
>>
>> Actors for WebSockets
>> 10.
>>
>>
>> Custom SSLEngine for HTTPS
>> 11.
>>
>>
>> Asset performance: faster serving, better caching.
>> 12.
>>
>>
>> One Result to rule them all: all the result types which were
>> deprecated in 2.2 are now gone and only Result remains. 13.
>>
>>
>> Lots of bug fixes. :)
>>
>>
>>
>> For details see the Play 2.3 Highlights
>> <http://www.playframework.com/documentation/2.3.x/Highlights23> and the
>> Play 2.3 Migration Guide
>> <http://www.playframework.com/documentation/2.3.x/Migration23>.
>>
>>
>> Download Play 2.3
>>
>>
>> Play is now distributed through Activator. Visit the Play downloads
>> <http://playframework.com/download> page for information on how to
>> download and install Activator, and get started with Play.
>>
>>
>> We would like in particular to thank the community for the many
>> contributions made. A bit of git number crunching tells us that *168*
>> unique contributors were involved in Play 2.3.x, and *132* of those had
>> not contributed to Play before. This brings us to an all time total
>> of *365* unique contributors to Play!
>>
>>
>>
>> Thanks,
>>
>>
>> The Play Team
>>
>>
>> --
>> *James Roper*
>> *Software Engineer*
>>
>>
>> Typesafe <http://typesafe.com/> – Build reactive apps!
>> Twitter: @jroper <https://twitter.com/jroper>
>>
>>
>> SEE YOU IN BERLIN <http://www.scaladays.org/>
>> Scala <http://www.scaladays.org/>
>> Days <http://www.scaladays.org/>
>> June 16th-18th, <http://www.scaladays.org/>
>> Berlin <http://www.scaladays.org/>

Michael Slinn

unread,
Jun 1, 2014, 12:33:04 AM6/1/14
to play-fr...@googlegroups.com
play.twirl.api.Html.empty is not provided, and I have used play.api.templates.Html.empty in many places. Its definition was:

def empty: Html = new Html(new StringBuilder)

Care to resurrect it?

Kevin Bowling

unread,
Jun 1, 2014, 1:48:56 AM6/1/14
to play-fr...@googlegroups.com
This is good stuff, upgrade from 2.2 on a medium sized codebase that started at 2.0 was very smooth.

I'd love for the docs on sbt-rjs to explain how it is used without any background on require.js.  Does it require you to rearchitect all your Javascript?

Regards,
Kevin

Endian Ogino

unread,
Jun 1, 2014, 11:15:20 AM6/1/14
to play-fr...@googlegroups.com
Thanks for the release!!

I found a little issue of activator.bat on a Windows system with a Java installation in the root folder C:\Program Files (x86)\
In line 199 of activator.bat %_JAVACMD% should be changed to "%_JAVACMD%" (mind the quotes) for the script to work properly.

Keep up the great work!!

Fernando Boaglio

unread,
Jun 1, 2014, 5:09:04 PM6/1/14
to play-fr...@googlegroups.com

New features are always welcome... but after 7 years change play command to activator is not good.

This would make deprecated all available documentation regarding previous releases (online and books).

It's like Oracle changing "java.exe"  to "activator-java.exe".

If the idea is to promote the activator, it should be another way to do it.


Dominik Dorn

unread,
Jun 1, 2014, 6:42:35 PM6/1/14
to play-fr...@googlegroups.com
my freshly downloaded activator seems broken. I can't run any play projects and the newly created ones are broken as well.

i'm running ubuntu 14.04 with oracle java 1.7.0_40

domdorn@camelion /tmp % activator new         

Fetching the latest list of templates...

Browse the list of templates: http://typesafe.com/activator/templates
Choose from these featured templates or enter a template name:
  1) minimal-java
  2) minimal-scala
  3) play-java
  4) play-scala
(hit tab to see a list of all templates)
> 4
Enter a name for your application (just press enter for 'play-scala')
> play-scala-test
OK, application "play-scala-test" is being created using the "play-scala" template.

To run "play-scala-test" from the command-line, run:
/tmp/play-scala-test/activator run

To run the test for "play-scala-test" from the command-line, run:
/tmp/play-scala-test/activator test

To run the Activator UI for "play-scala-test" from the command-line, run:
/tmp/play-scala-test/activator ui

domdorn@camelion /tmp % cd play-scala-test 
domdorn@camelion /tmp/play-scala-test
 % ls
activator  activator.bat  activator-launch-1.2.1.jar  app  build.sbt  conf  LICENSE  project  public  README  test
domdorn@camelion /tmp/play-scala-test
 % ./activator run
[info] Loading project definition from /tmp/play-scala-test/project
[info] Updating {file:/tmp/play-scala-test/project/}play-scala-test-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to play-scala-test (in build file:/tmp/play-scala-test/)
[info] Updating {file:/tmp/play-scala-test/}root...
[info] Resolving com.typesafe.play#play-jdbc_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#play-jdbc_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/play-jdbc_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/play-jdbc_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving com.typesafe.play#anorm_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#anorm_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/anorm_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/anorm_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving com.typesafe.play#play-cache_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#play-cache_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/play-cache_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/play-cache_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving com.typesafe.play#play-ws_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#play-ws_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/play-ws_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/play-ws_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving com.typesafe.play#play-test_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#play-test_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/play-test_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/play-test_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving com.typesafe.play#play-docs_2.11;2.3.0 ...
[warn] module not found: com.typesafe.play#play-docs_2.11;2.3.0
[warn] ==== local: tried
[warn]   /home/domdorn/.ivy2/local/com.typesafe.play/play-docs_2.11/2.3.0/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn]   file:/tmp/play-scala-test/repository/com.typesafe.play/play-docs_2.11/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn] ==== typesafe-releases: tried
[warn] ==== typesafe-ivy-releasez: tried
[warn] ==== Typesafe Releases Repository: tried
[info] Resolving jline#jline;2.11 ...
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] ::          UNRESOLVED DEPENDENCIES         ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: com.typesafe.play#play-jdbc_2.11;2.3.0: not found
[warn] :: com.typesafe.play#anorm_2.11;2.3.0: not found
[warn] :: com.typesafe.play#play-cache_2.11;2.3.0: not found
[warn] :: com.typesafe.play#play-ws_2.11;2.3.0: not found
[warn] :: com.typesafe.play#play-test_2.11;2.3.0: not found
[warn] :: com.typesafe.play#play-docs_2.11;2.3.0: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
sbt.ResolveException: unresolved dependency: com.typesafe.play#play-jdbc_2.11;2.3.0: not found
unresolved dependency: com.typesafe.play#anorm_2.11;2.3.0: not found
unresolved dependency: com.typesafe.play#play-cache_2.11;2.3.0: not found
unresolved dependency: com.typesafe.play#play-ws_2.11;2.3.0: not found
unresolved dependency: com.typesafe.play#play-test_2.11;2.3.0: not found
unresolved dependency: com.typesafe.play#play-docs_2.11;2.3.0: not found
at sbt.IvyActions$.sbt$IvyActions$$resolve(IvyActions.scala:217)
at sbt.IvyActions$$anonfun$update$1.apply(IvyActions.scala:126)
at sbt.IvyActions$$anonfun$update$1.apply(IvyActions.scala:125)
at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:115)
at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:115)
at sbt.IvySbt$$anonfun$withIvy$1.apply(Ivy.scala:103)
at sbt.IvySbt.sbt$IvySbt$$action$1(Ivy.scala:48)
at sbt.IvySbt$$anon$3.call(Ivy.scala:57)
at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:98)
at xsbt.boot.Locks$GlobalLock.xsbt$boot$Locks$GlobalLock$$withChannelRetries$1(Locks.scala:81)
at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:102)
at xsbt.boot.Using$.withResource(Using.scala:11)
at xsbt.boot.Using$.apply(Using.scala:10)
at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:62)
at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:52)
at xsbt.boot.Locks$.apply0(Locks.scala:31)
at xsbt.boot.Locks$.apply(Locks.scala:28)
at sbt.IvySbt.withDefaultLogger(Ivy.scala:57)
at sbt.IvySbt.withIvy(Ivy.scala:98)
at sbt.IvySbt.withIvy(Ivy.scala:94)
at sbt.IvySbt$Module.withModule(Ivy.scala:115)
at sbt.IvyActions$.update(IvyActions.scala:125)
at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1223)
at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1221)
at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$74.apply(Defaults.scala:1244)
at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$74.apply(Defaults.scala:1242)
at sbt.Tracked$$anonfun$lastOutput$1.apply(Tracked.scala:35)
at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1246)
at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1241)
at sbt.Tracked$$anonfun$inputChanged$1.apply(Tracked.scala:45)
at sbt.Classpaths$.cachedUpdate(Defaults.scala:1249)
at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1214)
at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1192)
at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:42)
at sbt.std.Transform$$anon$4.work(System.scala:64)
at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
at sbt.Execute.work(Execute.scala:244)
at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:160)
at sbt.CompletionService$$anon$2.call(CompletionService.scala:30)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
[error] (*:update) sbt.ResolveException: unresolved dependency: com.typesafe.play#play-jdbc_2.11;2.3.0: not found
[error] unresolved dependency: com.typesafe.play#anorm_2.11;2.3.0: not found
[error] unresolved dependency: com.typesafe.play#play-cache_2.11;2.3.0: not found
[error] unresolved dependency: com.typesafe.play#play-ws_2.11;2.3.0: not found
[error] unresolved dependency: com.typesafe.play#play-test_2.11;2.3.0: not found
[error] unresolved dependency: com.typesafe.play#play-docs_2.11;2.3.0: not found
[error] Total time: 7 s, completed Jun 2, 2014 12:37:21 AM
domdorn@camelion /tmp/play-scala-test





--
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.



--
Dominik Dorn
http://dominikdorn.com
http://twitter.com/domdorn

Skripten, Mitschriften, Lernunterlagen, etc. findest Du auf http://www.studyguru.eu !

Rich Dougherty

unread,
Jun 1, 2014, 6:44:02 PM6/1/14
to play-framework
Hi Fernando

The goal is to refactor some of the good stuff out of the play command so that we can reuse it across other open source projects, not just Play. At the moment Activator has an improved new command and a ui command to make it easier for new users. In the future we're going to try and generalise some of the other good stuff about play such as on-demand compiling with the run command so that, e.g. other frameworks can have automatic recompiles and reloading too. The benefit to Play is that we're going to get much more robust and powerful dev tools over time.

Anyway that's the goal, but it's a good point about being potentially confusing. What do you think we should do? E.g. one idea would be to provide an alias to activator called play.

Cheers
Rich

--
Rich Dougherty - @richdougherty
Engineer - Typesafe, Inc

Rich Dougherty

unread,
Jun 1, 2014, 6:47:52 PM6/1/14
to play-framework
Hi Dominik

We're currently investigating problems with the Typesafe artifact repository. Sorry about the inconvenience. If you look at the other threads on this mailing list you'll see more discussion of the issue.

In the meantime you could try downloading the offline distribution (331MB): http://downloads.typesafe.com/typesafe-activator/1.2.1/typesafe-activator-1.2.1.zip

Cheers
Rich
Rich Dougherty - @richdougherty
Engineer - Typesafe, Inc

Dominik Dorn

unread,
Jun 1, 2014, 7:02:23 PM6/1/14
to play-fr...@googlegroups.com
Hi Rich,

I created the new project with exactly this version of the offline distribution.. 

Hope it works soon. 

Cheers,
Dominik

Kostas kougios

unread,
Jun 1, 2014, 7:16:08 PM6/1/14
to play-fr...@googlegroups.com
I am too having issues with the repository:

[warn]     module not found: com.typesafe.play#build-link;2.3.0
[warn] ==== typesafe-ivy-releases: tried
[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/build-link/2.3.0/ivys/ivy.xml
[warn] ==== sbt-plugin-releases: tried
[warn]   http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.play/build-link/2.3.0/ivys/ivy.xml
[warn] ==== local: tried
[warn]   /home/ariskk/.ivy2/local/com.typesafe.play/build-link/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn]   http://repo1.maven.org/maven2/com/typesafe/play/build-link/2.3.0/build-link-2.3.0.pom
[warn] ==== Sonatype snapshots: tried
[warn]   http://oss.sonatype.org/content/repositories/snapshots/com/typesafe/play/build-link/2.3.0/build-link-2.3.0.pom
[warn] ==== Typesafe repository: tried
[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/build-link/2.3.0/build-link-2.3.0.pom
[warn]     module not found: com.typesafe.play#play-exceptions;2.3.0
[warn] ==== typesafe-ivy-releases: tried
[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-exceptions/2.3.0/ivys/ivy.xml
[warn] ==== sbt-plugin-releases: tried
[warn]   http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.play/play-exceptions/2.3.0/ivys/ivy.xml
[warn] ==== local: tried
[warn]   /home/ariskk/.ivy2/local/com.typesafe.play/play-exceptions/2.3.0/ivys/ivy.xml
[warn] ==== public: tried
[warn]   http://repo1.maven.org/maven2/com/typesafe/play/play-exceptions/2.3.0/play-exceptions-2.3.0.pom
[warn] ==== Sonatype snapshots: tried
[warn]   http://oss.sonatype.org/content/repositories/snapshots/com/typesafe/play/play-exceptions/2.3.0/play-exceptions-2.3.0.pom
[warn] ==== Typesafe repository: tried
[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-exceptions/2.3.0/play-exceptions-2.3.0.pom
[warn]     module not found: com.typesafe.play#routes-compiler_2.10;2.3.0


Rich Dougherty

unread,
Jun 1, 2014, 8:04:32 PM6/1/14
to play-framework
Hi Dominik

That's strange, the offline distribution is supposed to work without any downloads. To make sure I understand, were these your steps?

1. You download the offline distribution.
2. You ran activator and created a new project from the play-scala template.
3. You ran activator run.
4. Dependencies started downloading (which should need to happen).
5. Some dependencies weren't located (because the repo is down).

Cheers
Rich

Rich Dougherty

unread,
Jun 1, 2014, 8:09:42 PM6/1/14
to play-framework
Here's another thing to try. Add the following line to your project's project/plugins.sbt file.

resolvers += "Typesafe Maven Repository" at "http://repo.typesafe.com/typesafe/maven-releases/"

It didn't work for me with the minimal distribution (still didn't resolve jnotify), but it might work with the full offline distribution. It's worth a try anyway!

Cheers
Rich

eric grobler

unread,
Jun 1, 2014, 8:57:22 PM6/1/14
to play-fr...@googlegroups.com
Anyway that's the goal, but it's a good point about being potentially confusing. What do you think we should do? E.g. one idea would be to provide an alias to activator called play.


A "play" alias makes a lot of sense. 

Mike Slinn

unread,
Jun 1, 2014, 9:13:34 PM6/1/14
to play-fr...@googlegroups.com
Having one bloated executable that contains every possible feature is
not the way to go. Activator is more than 100MB larger than Play was. It
should be modularized, with dynamically loaded modules, or versions with
various features provided.

Mike

Megazord

unread,
Jun 1, 2014, 10:23:29 PM6/1/14
to play-fr...@googlegroups.com
I agree that the full Activator package is huge, but I don't think the problem is relevant, since you don't have to download it often. Anyway, this discussion was triggered by a repository problem that is already solved and we could now use the activator minimal.

About play command vs activator command, I think this could be treated as a deprecation issue. Just keep the play command for a while and print a warning every time it was used. After some releases, just remove the old play command at all.

best,

Rich Dougherty

unread,
Jun 1, 2014, 10:24:18 PM6/1/14
to play-framework
On Mon, Jun 2, 2014 at 1:13 PM, Mike Slinn <msl...@gmail.com> wrote:
Having one bloated executable that contains every possible feature is not the way to go. Activator is more than 100MB larger than Play was. It should be modularized, with dynamically loaded modules, or versions with various features provided.

Yeah, sorry about the big download. The download size is not really Activator's fault, I think it's mostly because Play has support for two versions of Scala this time so many of the dependencies are duplicated. I think there were some other dependency problems too, but I didn't work on the bundling so I'm not sure of the details.

There are probably a few things that could be done to make the distribution smaller, but we ran out of time for the final release. If we get a chance we'll try to make it smaller for 2.3.1.

Cheers
Rich

Havoc Pennington

unread,
Jun 1, 2014, 10:48:32 PM6/1/14
to play-framework
James has explained that Play's previous all-deps-bundled zip would
also have been larger in 2.3:
https://groups.google.com/d/msg/play-framework/-Wuopt6NAxg/OqSt_mIbUzAJ

The large activator download contains every transitive dependency of
Play, sbt, and the featured templates (which we try to keep using the
same dep versions as Play, so they shouldn't add much).

The smaller Play zip in earlier versions was due to stars aligning
such that the transitive dependency set didn't contain a lot of
duplication in that particular release.

You can download the 1M version of Activator which will just use your
existing Ivy cache and dynamically load dependencies on demand.

To give some examples of why the dependency set is now larger:

* in play 2.3 is that sbt 0.13 has to stick to scala 2.10.x to avoid
breaking all plugins. So in Play 2.3 we inherently have to pull in
scala 2.10 in order to run sbt, but play 2.3 itself uses scala 2.11.

* activator 1.2.1 has an extra copy of Scala 2.11.x because (I think)
scalatest is compiled against 2.11.0 instead of 2.11.1, and even
though Ivy ends up using 2.11.1 it needs to look at 2.11.0 in the
local repository in order to work. Blurgh. But it's not activator's
doing, this is a bad interaction between Ivy and scalatest. One that
may be fixed when new scalatest comes out against 2.11.1 (assuming no
other package starts using 2.11.2 in the meantime...).

To avoid duplication we have to get EVERY dependency to agree on the
versions of the transitive dependencies. This is painful.

Would definitely appreciate help chasing down all these kinds of
issues, every time we release there are some new ones. In the long run
clearly we need to enhance Ivy or somehow make things smarter to avoid
some of the duplication (but the work here would be generic Ivy/sbt
work, not activator work, afaik).

Like the "play" script before it, activator is just sbt with a couple
of extra command line tricks. In Activator's case they are "activator
ui" and "activator new," which you need not ever run. If you don't run
those then you can just as well download the sbt launcher, just as you
could always just use the sbt launcher for Play 2.2 instead of getting
the play command. The play -> activator transition is mostly supposed
to be about making the "new" command work for non-play apps too (and
making it extensible - anyone can publish templates).

You probably saw it already but for those who have not I tried to give
more Activator background in this blog post:
https://typesafe.com/blog/typesafe-activator---an-update-and-roadmap-preview

Many apologies for the repository issues today which were causing a
lot of trouble (fwiw they also hosed up some work I was trying to do
and I was very confused).

Havoc
(also havoc.pennington typesafe.com but I subscribed to this list
before I had that address)

Fernando Boaglio

unread,
Jun 1, 2014, 11:31:57 PM6/1/14
to play-fr...@googlegroups.com


Hi Rich,

 
Anyway that's the goal, but it's a good point about being potentially confusing. What do you think we should do? E.g. one idea would be to provide an alias to activator called play.


I think an alias is not enough.

With Activator, you can create too much stuff that is not Play related, like vaadin-in-akka.

The best way to fix it is to keep the old play command line with an option to call the activator:


fb@cascao ~ [ 0:29:50]> play new test
       _
 _ __ | | __ _ _  _
| '_ \| |/ _' | || |
|  __/|_|\____|\__ /
|_|            |__/

play 2.2.3 built with Scala 2.10.3 (running Java 1.8.0_05), http://www.playframework.com

The new application will be created in /home/fb/test

What is the application name? [test]
>

Which template do you want to use for this new application?

  1             - Create a simple Scala application
  2             - Create a simple Java application
  3             - Create a application with Activator

>



Megazord

unread,
Jun 2, 2014, 1:19:19 AM6/2/14
to play-fr...@googlegroups.com
And so we will have a circular dependency between play package and activator package, right?

Anyway, I don't think that moving from play command to activator command is that difficult or annoying. Actually, this was the simplest change to do while upgrading my project to Play 2.3.0. But I can understand that this "invalidates" tutorials and other information that are outside of official docs. That is why my suggestions is just provide an alias that warns the users about the command deprecation.

Best,

Mike Slinn

unread,
Jun 2, 2014, 1:25:41 AM6/2/14
to play-fr...@googlegroups.com
I'd like to suggest tweaking priorities:
  1. De-emphasize the importance of delivering big releases according to a demanding schedule. Instead focus on quality, integration, documentation and usability.
  2. More point releases, tuning work that has been done, less major releases with breaking features.
  3. More time spent planning and communicating; the current situation is a textbooks case that illustrates what happens when product management is lacking. We've got a mess at this time, with products (Scala 2.10/11, Slick and Play) that do not work effectively together.
    1. More engagement with community re. potential roadmaps
    2. More transparency and public accountability in the planning process; yes, being accountable to users should be a goal.
    3. Curated release notes
    4. Coordinated release schedule with Scala compiler and Slick.
  4. Fewer new features; make them really count and plan ahead so new or modified features rarely break functionality. My top wish list items are:
    1. Much better Slick integration (Play and Slick developers should work as one team). The Play community is Slick's biggest user base, so the needs of Play should be a major driver of the Slick roadmap.
    2. Overcome all arity 22 issues (which means supporting > 18 fields/form)
    3. Strong focus on testability of Play projects

Thanks,

Mike

James Roper

unread,
Jun 2, 2014, 2:47:15 AM6/2/14
to play-framework
On Mon, Jun 2, 2014 at 3:25 PM, Mike Slinn <msl...@gmail.com> wrote:
I'd like to suggest tweaking priorities:
  1. De-emphasize the importance of delivering big releases according to a demanding schedule. Instead focus on quality, integration, documentation and usability.
There is always a balance to be had.  We could become Java/JEE, never break anything, have 2-3 year release cycles.  This would mean stopping, saying "Play's approach to everything is good enough, let's focus only on improvements that don't break things".  Does the Play community want Play to stop at being a nicer Java/JEE, or continue to be a cutting edge framework?  Over time, priorities will change, and we will see this happen in Play, but the question is, how quickly do we slow down?

Right now, we have 2 big things that we are not happy with:

* Global state
* Async IO API that is incredibly difficult for scala developers to use and impossible to use from java (iteratees)

It's for these reasons that Play is going to break over the next releases.

The biggest breaking changes we've made in Play 2.3.0 have been around client side integration.  This is one aspect where Play's quality really sucked - our less compiler was slow and had massive issues, all of our client side support had fundamental limitations that prevented anything but the bare minimum from being done with them.  sbt-web is a focus on quality and integration in that respect.

On documentation, our focus has been on quality.  We've now almost finished extracting the code samples in the Play docs out into compiled and tested code, this is a huge task, and has and will continue to make a huge difference in future releases.  We've rewritten major portions of the documentation to make it friendlier for newcomers, including the WS documentation and JSON support.  And this is all with a team with an average of only 3 full time developers.

The major breaking changes over the past 2 major releases of Play have been around usability - the biggest being the way Results work.  This was triggered by a very long public discussion on the Play developer mailing list.
  1. More point releases, tuning work that has been done, less major releases with breaking features.
  1. More time spent planning and communicating; the current situation is a textbooks case that illustrates what happens when product management is lacking. We've got a mess at this time, with products (Scala 2.10/11, Slick and Play) that do not work effectively together.
How is this so?  Play works with Scala 2.11, Slick has Scala 2.11 support on the way.  I don't see how that's a mess.
    1. More engagement with community re. potential roadmaps
In my opinion, engagement with an open source community best happens at the point where the community contributes to the project.  Nothing speaks louder about what the community wants when many members of the community invest their time into a project by raising issues, discussing issues, implementing solutions, reviewing changes, etc.  I check the activity on the issue tracker every day, and the discussions there have a huge impact into what we focus on in Play.  One of the most active discussions/pull requests is the pull request on support for dependency injection of plugins, this is going to be one of the major focuses of Play 2.4.
    1. More transparency and public accountability in the planning process; yes, being accountable to users should be a goal.
I'm not sure what you're after here that we don't already do.  And I don't think that's the way open source works - open source software owes nothing to its users, it's the other way around, open source software advances when users take responsibility and invest their time into it.  People that want to be involved in the planning process involve themselves, they initiate discussions, they make suggestions for solutions, they involve themselves in reviews.  We have recently added four new committers from the community onto Play, these were users who did exactly that on a regular basis.
    1. Curated release notes
    1. Coordinated release schedule with Scala compiler and Slick.
I'm not sure why this should be a big issue - so you can't use Scala 2.11 with Play 2.3 and Slick today... but is that a real issue?  Is there anything wrong with waiting until Slick 2.1 is released?  Or should we have sat on the Play 2.3.0 and Scala 2.11 releases until the day Slick 2.1 was released?  What is to be gained by doing that?
  1. Fewer new features; make them really count and plan ahead so new or modified features rarely break functionality. My top wish list items are:
    1. Much better Slick integration (Play and Slick developers should work as one team). The Play community is Slick's biggest user base, so the needs of Play should be a major driver of the Slick roadmap.
This is already a big ticket item for Play 2.4.
    1. Overcome all arity 22 issues (which means supporting > 18 fields/form)
This may be a big issue for you, but we haven't come across a huge number of users for whom this is an issue and/or the work arounds aren't sufficient.  Nevertheless, work has been done to chip away at this, it's a very difficult problem to solve in Scala, but they are slowly improving it.
    1. Strong focus on testability of Play projects
This is going to be a major focus in both Play 2.4, and Play 3.0.  The biggest hinderance of testability in Play projects is global state.  Fixing that, unfortunately, requires major breaking changes.

It seems to me that your feature list is already heavily featured on the Play roadmap - that says to me we must be doing something right as far as engaging the community is concerned.

Thanks,

Mike

--
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.

Steven Marcus

unread,
Jun 2, 2014, 8:41:00 AM6/2/14
to play-fr...@googlegroups.com

* Async IO API that is incredibly difficult for scala developers to use and impossible to use from java (iteratees)

Happy to hear that this is acknowledged and being looked at. I know that Akka is adding stream support, but the RxJava library has the advantage that there is a companion RxJS library supported by MS. Gaining an easy to use streaming bridge between the server and the browser would make building reactive web apps much more pleasant...

I know that WebSockets are "the thing" and a solution like Spring's WebSocket with SockJS fallback would be great... but EventSource support could be really useful too for some use-cases. Especially with a polyfill, perhaps https://github.com/Yaffle/EventSource/

As far as "community contributions" and stability of releases go, I value and use Play because it is a "cutting-edge" web framework. But, as a user of SecureSocial, I've noticed how much work (for the author of SecureSocial) it's been to keep up with Play during the 2.0->2.1->2.2 releases, and 2.3 support is not yet available. It doesn't look like things are going to settle any time soon, given the roadmap for 2.4 and the (much needed) DI changes, et al.

Which brings me to a feature not currently on the roadmap, but important: OAuth2 / JWT support. I guess it's not that difficult but it's so pervasive in real-world apps that it seems like it should be in the framework?

Congrats on the new release, and the roadmap looks great too...




 

Ryan Tanner

unread,
Jun 2, 2014, 12:35:18 PM6/2/14
to play-fr...@googlegroups.com
I'm very glad to hear that the elimination of play.api.Play.current is on the table.  That is a huge hinderance to getting tests to behave correctly IME.  I've given up on it and just pass an implicit Application around instead so I can control it in testing.

Marc Siegel

unread,
Jun 2, 2014, 1:11:47 PM6/2/14