Introducing Play 2.3.0

18161 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
to play-fr...@googlegroups.com, Derek Henninger, Sushila Sahay
+1

I'd like to emphasize how closely Michael Slinn's priority recommendations here match our own at TIM Group. Typesafe folks?

Mike Slinn

unread,
Jun 2, 2014, 1:26:26 PM6/2/14
to play-fr...@googlegroups.com
I appreciate the time everyone has taken to carefully discuss the issues I raised.

When I teach Scala and Play, I am conscious of two main types of students: those who have already made a committment to the technology, and those who are taking training as a way of evaluating the technology. The issues raised by the two groups are quite different. It is only natural that those who have already made a commitment find that the existing products suit their needs. There are a significant number of uncommitted students who, after learning about the technology, decide not to adopt the technology. The issues I outlined are based on feedback received from them.

I believe that if Scala and Play are to move past the technology adoption lifecycle chasm, and be adopted by Pragmatists instead of just being adopted by the much smaller number of Visionaries, then the priorities of Pragmatists will need to be adopted, and messaging and methodologies will need to be modified to suit.

Thank you,

Mike

Peter Vlugter

unread,
Jun 2, 2014, 7:18:28 PM6/2/14
to play-framework
For now it can be found at play.twirl.api.HtmlFormat.empty

https://github.com/playframework/twirl/blob/master/api/src/main/scala/play/twirl/api/Formats.scala#L77

It was moved from Html to HtmlFormat a while ago, before moving the templates to twirl:

https://github.com/playframework/playframework/commit/5c8346e

- Peter

Message has been deleted

Jonathan Parsons

unread,
Jun 3, 2014, 2:11:47 AM6/3/14
to play-fr...@googlegroups.com
This is such an awesome build. The asset pipeline is a million times better now. Thank you!

Łukasz Śliwiński

unread,
Jun 3, 2014, 4:17:32 AM6/3/14
to play-fr...@googlegroups.com
I agree with most of what you are saying. I don't know what marketing plans have Typesafe folks but from my point of view as a developer/team leader that want to use play framework on professional, commercial, daily work I'm not sure how many changes I had to make to my product to stay with "new vision". Also stability in play framework features is quite moot. Please look into new 2.3 threads of play!'s google groups. For now it looks like quite interesting framework with some nice features but only usable as toy, not professional product. Effect is that we are getting play! releases that are more like curiosity but not really production ready product. Personally I will probably stay with 2.2.3 that looks quite good with assets-loader and play-hikaricp and wait for some "LTS" release when developers and designers of play will have more crystallized vision and will be happy with most of the changes made to the library.

Marius Soutier

unread,
Jun 3, 2014, 10:04:33 AM6/3/14
to play-fr...@googlegroups.com
Play 2.3 focussed on what it was lacking the most and what was requested by many - a configurable, extendable asset pipeline. And now we have one of the best.
Play sits on top of Akka, a mature platform for building concurrent applications, and most of your development time should be spent there (there was a saying once, “Rails is not your application”, and the same applies to Play).

And yes, of course you should not update your production environment to a x.x.0 release, but that goes for all software products (I never update Mac OS or iOS before x.x.1).


James Duncan Davidson

unread,
Jun 4, 2014, 3:00:07 AM6/4/14
to play-fr...@googlegroups.com
FWIW, I'm seeing the "download the world" behavior as well in a clean docker container with just Ubuntu 14.04, Java 8, and Activator 1.2.1. Setting the IVY_HOME environment variable to to the repository in the distribution helps quite a bit as the downloads at pulled from file:/ URLs, but there's still a huge amount of churn and duplication as the examples come up. For example, just firing up the Hello Scala example produces output like this:

  • [SUCCESSFUL ] org.scala-sbt#compiler-integration;0.13.5!compiler-integration.jar (50ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/compiler-ivy-integration/0.13.5/jars/compiler-ivy-integration.jar ...
  • [SUCCESSFUL ] org.scala-sbt#compiler-ivy-integration;0.13.5!compiler-ivy-integration.jar (48ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/relation/0.13.5/jars/relation.jar ...
  • [SUCCESSFUL ] org.scala-sbt#relation;0.13.5!relation.jar (44ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/task-system/0.13.5/jars/task-system.jar ...
  • [SUCCESSFUL ] org.scala-sbt#task-system;0.13.5!task-system.jar (26ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/tasks/0.13.5/jars/tasks.jar ...
  • [SUCCESSFUL ] org.scala-sbt#tasks;0.13.5!tasks.jar (29ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/tracking/0.13.5/jars/tracking.jar ...
  • [SUCCESSFUL ] org.scala-sbt#tracking;0.13.5!tracking.jar (73ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-sbt/testing/0.13.5/jars/testing.jar ...
  • [SUCCESSFUL ] org.scala-sbt#testing;0.13.5!testing.jar (39ms)
  • downloading file:/opt/activator-1.2.1/repository/org.scala-lang/scala-compiler/2.10.4/jars/scala-compiler.jar ...
  • [SUCCESSFUL ] org.scala-lang#scala-compiler;2.10.4!scala-compiler.jar (581ms)

Even for a simple Hello Scala example, this goes on for a minute or so. It's worse in the larger examples.

This is the Dockerfile used to build the container: https://index.docker.io/u/duncan/activator/
Rich

<p dir="
...

Rich Dougherty

unread,
Jun 4, 2014, 6:06:56 AM6/4/14
to play-framework
Hi Duncan

That behaviour doesn't sound right to me. I wonder if Activator's confused by the symlink?

Would you mind reporting an Activator bug? Starting from a clean docker container makes your bug easy nice and easy to reproduce. :)


Cheers
Rich

Sander Sõnajalg

unread,
Jun 4, 2014, 8:15:21 AM6/4/14
to play-fr...@googlegroups.com
Hi,

tried the upgrade to 2.3.0. The migration guide is very helpful. A couple of comments/suggestions:

1) I have a large custom Build.scala, I used to define settings like that:

 lazy val main = Project(appName, file("."), settings = Defaults.defaultSettings /* ++ otherSettings*/).enablePlugins(play.PlayJava)

With the latest play/SBT upgrade, the deprecated method Defaults.defaultSettings has to be changed for Defaults.coreDefaultSettings, or it won't find sources to compile. It might be good to mention that in the migration guide.

2) Also the method deprecated in 2.2., Akka#future, has now been removed. It took some time to find out that it has to be replaced with Promise#promse. Maybe also mention that in the guide..?

3) Biggest issue is actually Deadbolt 2, due to which I am actually currently unable to complete the migration, it seems. This project hasn't kept track with with the quick appearance and then again disappearance of the SimpleResult type. I tried to make use of the "placeholder" type SimpleResult in 2.3.x, but wasn't able to get it to compile, still (methods are chained and eventually somebody still exepects the result to be Result and not a SimpleResult). Also created them an issue - https://github.com/schaloner/deadbolt-2/issues/47 .. I'm not sure if this project is connected with Typesafe in any awy. (I have to mention that although the deprecate-before-delete process has been followed, I guess the API has been changing a bit too quickly recently. I might be able to keep track of the quick changes with my own code base (if there's a migration guide), but if third party dependencies can't keep up with it, the end-user will be helpless). Otherwise seems you're making quick progress!

Cheers,
Sander.


Eric Jain

unread,
Jun 5, 2014, 1:37:21 AM6/5/14
to play-fr...@googlegroups.com
Nice! I'm eager to try the new asset pipeline... But first: Has any of this been tested on Windows yet? :-)

James Duncan Davidson

unread,
Jun 5, 2014, 4:16:53 AM6/5/14
to play-fr...@googlegroups.com
Hi Rich, it shouldn’t be. I’ll try it without the symlink when I get some time later. And yes, the clean docker container does make it nice and isolated. :)


Thanks! -Duncan

Suraj Mundada

unread,
Jun 5, 2014, 9:15:54 AM6/5/14
to play-fr...@googlegroups.com
Hi,

I am new to Play. Have started with Play 2.3.0 by downloading offline version (331M).

I launched activator ui and tried running Hello-akka sample. But getting error:

"download failed: org.scala-lang#scala-compiler;2.10.2!scala-compiler.jar"

Should I donwload scala-compiler-2.10.2.jar and add it to "activator-1.2.1\repository\org.scala-lang\scala-compiler\2.10.2" folder as scala-compiler.jar?

Regards,
Suraj


On Saturday, May 31, 2014 4:55:44 AM UTC+5:30, 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.)

  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

Michael Slinn

unread,
Jun 5, 2014, 11:19:25 AM6/5/14
to play-fr...@googlegroups.com
Eric,

Windows is not your friend when developing with this stack. If you *must* use Windows, install piles of RAM and run VMware to host Linux.

Mike

Rich Dougherty

unread,
Jun 5, 2014, 8:18:24 PM6/5/14
to play-framework
Hi Eric

Play supports Windows but I will admit that we do rely a little more on end users to test Windows than we do on other platforms. I've recently looked at Codeship to provide CI on Windows but it needs more investigation.

Cheers
Rich


On Thu, Jun 5, 2014 at 5:37 PM, Eric Jain <eric...@gmail.com> wrote:
Nice! I'm eager to try the new asset pipeline... But first: Has any of this been tested on Windows yet? :-)

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

Rich Dougherty

unread,
Jun 5, 2014, 8:21:46 PM6/5/14
to play-framework

Eric Jain

unread,
Jun 6, 2014, 4:05:41 PM6/6/14
to play-fr...@googlegroups.com
On Thursday, June 5, 2014 5:21:46 PM UTC-7, Rich Dougherty wrote:
Play supports Windows but I will admit that we do rely a little more on end users to test Windows than we do on other platforms. I've recently looked at Codeship to provide CI on Windows but it needs more investigation.

I wouldn't mind spending more time testing and reporting issues, if I knew Windows-only issues were considered important enough to warrant bugfix releases.

Here are two such issues, both with easy fixes; let's see how long it takes before they make it into a release...

- OutOfMemory even for small projects [https://github.com/typesafehub/activator/pull/539]
- sbt-rjs doesn't work [https://github.com/sbt/sbt-rjs/issues/14]

Havoc Pennington

unread,
Jun 6, 2014, 5:09:34 PM6/6/14
to play-framework
On Fri, Jun 6, 2014 at 4:05 PM, Eric Jain <eric...@gmail.com> wrote:
> Here are two such issues, both with easy fixes; let's see how long it takes
> before they make it into a release...
>
> - OutOfMemory even for small projects
> [https://github.com/typesafehub/activator/pull/539]

I released this in activator 1.2.2 yesterday (AFAIK)

Havoc

Eric Jain

unread,
Jun 11, 2014, 6:03:37 PM6/11/14
to play-fr...@googlegroups.com
On Friday, June 6, 2014 2:09:34 PM UTC-7, Havoc Pennington wrote:
I released this in activator 1.2.2 yesterday (AFAIK)

That was fast, thanks.

Still waiting for the sbt-rjs fix to be released; someone contributed a fix last week, but there hasn't been a bugfix release yet...

swastika basu

unread,
Jun 16, 2014, 10:13:32 AM6/16/14
to play-fr...@googlegroups.com
Hi James,

Is there any jenkins plugin available for this version?

Thanks,
Swastika

Chanan Braunstein

unread,
Jun 16, 2014, 4:24:56 PM6/16/14