Introducing Play 2.3.0

[James Roper]

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

SEE YOU IN BERLIN

Scala

Days

June 16th-18th,

Berlin

[Mateusz Szczap]

This is excellent news, thank you for your hard work!

[Andy Czerwonka]

Fantastic! Can't wait to upgrade.

[Korrawit Yindeeyoungyeon]

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]

Shouldn't this thread be pinned instead of the RC2 one?

[Julien Richard-Foy]

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]

Great job!

[Martin Grotzke]

Awesome, thanks for your great work!

--

[juan....@reduc.edu.cu]

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]

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]

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]

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]

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]

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]   http://repo1.maven.org/maven2/com/typesafe/play/play-jdbc_2.11/2.3.0/play-jdbc_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-jdbc_2.11/2.3.0/play-jdbc_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-jdbc_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-jdbc_2.11/2.3.0/play-jdbc_2.11-2.3.0.pom

[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]   http://repo1.maven.org/maven2/com/typesafe/play/anorm_2.11/2.3.0/anorm_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/anorm_2.11/2.3.0/anorm_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/anorm_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/anorm_2.11/2.3.0/anorm_2.11-2.3.0.pom

[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]   http://repo1.maven.org/maven2/com/typesafe/play/play-cache_2.11/2.3.0/play-cache_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-cache_2.11/2.3.0/play-cache_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-cache_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-cache_2.11/2.3.0/play-cache_2.11-2.3.0.pom

[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]   http://repo1.maven.org/maven2/com/typesafe/play/play-ws_2.11/2.3.0/play-ws_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-ws_2.11/2.3.0/play-ws_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-ws_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-ws_2.11/2.3.0/play-ws_2.11-2.3.0.pom

[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]   http://repo1.maven.org/maven2/com/typesafe/play/play-test_2.11/2.3.0/play-test_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-test_2.11/2.3.0/play-test_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-test_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-test_2.11/2.3.0/play-test_2.11-2.3.0.pom

[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]   http://repo1.maven.org/maven2/com/typesafe/play/play-docs_2.11/2.3.0/play-docs_2.11-2.3.0.pom

[warn] ==== typesafe-releases: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-docs_2.11/2.3.0/play-docs_2.11-2.3.0.pom

[warn] ==== typesafe-ivy-releasez: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.play/play-docs_2.11/2.3.0/ivys/ivy.xml

[warn] ==== Typesafe Releases Repository: tried

[warn]   http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-docs_2.11/2.3.0/play-docs_2.11-2.3.0.pom

[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]

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]

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]

Hi Rich,

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

Hope it works soon. 

Cheers,

Dominik

[Kostas kougios]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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:
   

The Play 2.4 roadmap is here:

https://docs.google.com/a/typesafe.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA/pub

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]

* 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]

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]

+1

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

[Mike Slinn]

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]

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

[Jonathan Parsons]

This is such an awesome build. The asset pipeline is a million times better now. Thank you!

[Łukasz Śliwiński]

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]

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]

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]

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

https://github.com/typesafehub/activator/issues

Cheers

Rich

[Sander Sõnajalg]

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]

Nice! I'm eager to try the new asset pipeline... But first: Has any of this been tested on Windows yet? :-)

[James Duncan Davidson]

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

Bug reported: https://github.com/typesafehub/activator/issues/544

Thanks! -Duncan

[Suraj Mundada]

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]

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]

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]

Created an issue: https://github.com/playframework/playframework/issues/2997

[Eric Jain]

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]

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]

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]

Hi James,

Is there any jenkins plugin available for this version?

Thanks,

Swastika

[Chanan Braunstein]

You can just use the sbt plugin for Jenkins. Works like a charm.

[swastika basu]

Thanks chanan..will try that..the existing play framework Jenkins plugin doesn't seem to work with play 2.3.

> --
> 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/bTvJbeR_zvU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[ch...@ridepal.com]

YES!!

I can't agree more with Fernando's comment.  By continually changing fundamental components like how to start the application, you're relegating the Play Framework to non-production side projects.

Chris

On Sunday, June 1, 2014 2:09:04 PM UTC-7, Fernando Boaglio wrote:

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.

[alex s]

среда, 18 июня 2014 г., 1:47:27 UTC+4 пользователь ch...@ridepal.com написал:

changing fundamental components like how to start the application

Fundamental, huh? Just rename activator to play and pretend that didn't happen.

[ch...@ridepal.com]

Alex S - Yes, fundamental.  Play is not now simply called Activator.  Major changes include:

 - The build process has changed and is not backwards compatible

 - Results objects

 - Twirl templating engine

 - Web Services and their timeout defaults

All of these bullets require application code updates and appropriate testing for production environments.

Chris

[David Pichsenmeister]

way too many major changes on a minor upgrade.

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

I can't use activator clean-all like I could use with play command, so that's not true.

Also, renaming classes in a minor upgrade is a pain. I'm now struggling the whole day with migrating from 2.2.2 to 2.3.0 and that shouldn't be that much work! I'm really losing a bit of trust in typesafe.

[alex s]

I'm not sure 2.2 -> 2.3 can be considered a minor upgrade. You are expected to put some amount of work in upgrading when the y in x.y.z changes. Scala itself and Akka use the same numbering scheme.

[James Ward]

Yeah it seems like there is definitely some misunderstanding on how Typesafe uses version numbers to indicate ease of migration.  Here is the scheme:

epoch.major.minor

Epoch is for massive architectural changes = weeks to upgrade.

Major is for incompatible changes that = days to upgrade.

Minor is for bug fixes = hours to upgrade.

Play 2.2 to 2.3 should not be expected to be a seamless upgrade.

-James

[Mariot Chauvin]

Is there any plan to switch to a more common versioning policy, like semantic versioning ?

Mariot

--

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.

---

Visit theguardian.com. On your mobile and tablet, download the Guardian iPhone and Android apps theguardian.com/guardianapp and our tablet editions theguardian.com/editions.  Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.  Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.  Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

 

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered in England Number 908396

[Eric Jain]

On Thursday, June 19, 2014 5:30:22 AM UTC-7, James Ward wrote:

Epoch is for massive architectural changes = weeks to upgrade.

Major is for incompatible changes that = days to upgrade.

Minor is for bug fixes = hours to upgrade.

Play 2.2 to 2.3 should not be expected to be a seamless upgrade.

I think the scope of the changes for the 2.3 release was reasonable. However, some suggestions:

- Deprecate features at least one major release before removing them.
- Release bug fixes as soon they are ready, not once every few months.

[virtualeyes]

FWIW, 2.2 to 2.3 upgrade was seamless here, just fix some deprecation warnings around SimpleResult and reference new Twirl package location.

Should be able to use sbt command in place of activator if desired (building from source here, not sure if activator command is required when downloading activator bundle).

Based on the issues brought up here on the list the new web plugin has been the biggest cause of confusion. Probably not enough early adopters during M/RC phases to flesh out the edge cases play-ers are hitting with the production release.

[Kevin Bowling]

The asset stuff has been working well for me but it was some serious pain figuring parts out as I'm neither an sbt expert nor a JavaScript expert and the docs are very light so far.  A sample project that makes heavy use of several sbt-web plugins would be a great thing to point to.  I couldn't figure out how to make sbt-uglify do anything I wanted.  After a lot of rage and fumbling around I got sbt-rjs working well but this required learning about JS AMD and porting all my JS to use it which was dubious at best.  concat+minification of certain files is all I really wanted.

Aside from that 2.2 to 2.3 was seamless for me on a codebase that started pre-2.0.  I stayed with Scala 2.10.4 initially and just switched to 2.11.1 after a Squeryl update was released today.

The activator command change is trivial.  When first announced it sounded strange but in practice it only affects development workstations.  Use sbt for CI and deployment.

Regards,
Kevin

[James Roper]

On Friday, June 20, 2014 10:49:30 AM UTC+10, Eric Jain wrote:

On Thursday, June 19, 2014 5:30:22 AM UTC-7, James Ward wrote:

Epoch is for massive architectural changes = weeks to upgrade.

Major is for incompatible changes that = days to upgrade.

Minor is for bug fixes = hours to upgrade.

Play 2.2 to 2.3 should not be expected to be a seamless upgrade.

I think the scope of the changes for the 2.3 release was reasonable. However, some suggestions:

- Deprecate features at least one major release before removing them.

I don't think there was anything deleted from 2.3 that wasn't deprecated in 2.2, if you have an example, please let us know.

That said, sometimes deprecation is not possible, for example, we had a bug in the SecurityHeaderFilter where the arguments to it should have been lazy (by name), but weren't.  This meant changing the signature of the constructor without deprecation - the scala compiler can't work out whether the by name constructor or the old constructor should be called at the call site, so we couldn't provide a deprecated constructor with the regular parameters.  Also, sometimes deprecation is not sufficient - if you change the behaviour of a method, there is no way to deprecate the old behaviour.  Deprecation therefore can only ever be a best effort thing, not something that you can ever put hard guarantees on.

 

- Release bug fixes as soon they are ready, not once every few months.

This is actually something that we explicitly don't do, and in fact, as a general rule we don't backport bug fixes to even the current stable release, unless it has a significant impact on enough people with no simple work around.

We do however offer this service to our paying customers.  Somehow, we have to find a way to differentiate between our paid subscription and the open source offerings, if we give identical service to both our paying customers and the open source community, then no one in their right mind would become a paying customer, and if we have no paying customers - well Play 2 would never have even existed in the first place.  Our reasoning for choosing this as one of the differentiators is that open source users can always create their own builds of Play Framework - the source code is there, we're not holding anything back.  It's just less convenient to do so.  So you have 3 options, pay to get the latest fixes with convenience, build your own to get the latest fixes, or wait for the next release to get fixes.

[Eric Jain]

On Sun, Jun 22, 2014 at 11:21 PM, James Roper <james...@typesafe.com> wrote:
> I don't think there was anything deleted from 2.3 that wasn't deprecated in
> 2.2, if you have an example, please let us know.

Was minification of (non-rjs) js assets deprecated in 2.2?

> Somehow, we have to find a way to differentiate between our paid
> subscription and the open source offerings, if we give identical service to
> both our paying customers and the open source community, then no one

> in their right mind would become a paying customer [...]

The incentive to be a paying customer is usually to have more reliable
support than the mailing list can provide; making bugfix releases
available to paying customers only seems counterproductive.

[Steven Marcus]

> Somehow, we have to find a way to differentiate between our paid
> subscription and the open source offerings, if we give identical service to
> both our paying customers and the open source community, then no one
> in their right mind would become a paying customer [...]

I think the business model is flawed if you have to keep _important_ fixes from being applied to the current branch in order to keep the cash flowing.
But I appreciate the fact that I can pull the latest fixes from a branch and publish into my local maven repo if I don't have a subscription.

For example, is the new netty release, with the important SSL updates, going to be available on the 2.3 branch any time soon?
(http://netty.io/news/2014/06/11/3.html) Sure I can update the dependency in my project, but people new to Play may well expect that the latest official release available from the web site will not have known vulnerabilities. (We deploy Play behind nginx -- so not an actual issue for me in this instance.)

I think it will better serve the Play community, and in the medium term Typesafe, to have shorter release cycles and to ensure that new people to Play don't encounter problems that are already solved.

This business problem is not new and all open source with paid support option projects have to deal with it. So I don't mean to single out Typesafe as worse than anyone else. And in many ways, Typesafe is better than many...

my 2c and all that...

[James Roper]

On Tue, Jun 24, 2014 at 8:59 AM, Steven Marcus <steven...@gmail.com> wrote:

> Somehow, we have to find a way to differentiate between our paid
> subscription and the open source offerings, if we give identical service to
> both our paying customers and the open source community, then no one
> in their right mind would become a paying customer [...]

I think the business model is flawed if you have to keep _important_ fixes from being applied to the current branch in order to keep the cash flowing.
But I appreciate the fact that I can pull the latest fixes from a branch and publish into my local maven repo if I don't have a subscription.

Important is a relative term :)  Most of the bug fixes since the 2.3 release have been backported to the 2.3.x branch - especially if it's a regression, we will backport.  And security fixes will most certainly be backported.  In practice, we have a conservative official policy, but then we tend to be quite liberal about it.  After all, we want, and need the community to succeed.

For example, is the new netty release, with the important SSL updates, going to be available on the 2.3 branch any time soon?
(http://netty.io/news/2014/06/11/3.html) Sure I can update the dependency in my project, but people new to Play may well expect that the latest official release available from the web site will not have known vulnerabilities. (We deploy Play behind nginx -- so not an actual issue for me in this instance.)

I wasn't aware of this (have been travelling for the past 2 weeks, only just getting back into the swing of things, recovering from jetlag etc).  Yes, we will definitely update Netty on the 2.3 branch.

I think it will better serve the Play community, and in the medium term Typesafe, to have shorter release cycles and to ensure that new people to Play don't encounter problems that are already solved.

On point releases, I think the biggest issue is time - Typesafe currently employs 2 1/2 full time devs to work on Play - that's not a lot.  Cutting releases takes time and planning, not something we want to be doing every week for example.

 

This business problem is not new and all open source with paid support option projects have to deal with it. So I don't mean to single out Typesafe as worse than anyone else. And in many ways, Typesafe is better than many...

my 2c and all that...



On Tuesday, 24 June 2014 08:21:50 UTC+10, Eric Jain wrote:

On Sun, Jun 22, 2014 at 11:21 PM, James Roper <james...@typesafe.com> wrote:
> I don't think there was anything deleted from 2.3 that wasn't deprecated in
> 2.2, if you have an example, please let us know.

Was minification of (non-rjs) js assets deprecated in 2.2?


> Somehow, we have to find a way to differentiate between our paid
> subscription and the open source offerings, if we give identical service to
> both our paying customers and the open source community, then no one
> in their right mind would become a paying customer [...]

The incentive to be a paying customer is usually to have more reliable
support than the mailing list can provide; making bugfix releases
available to paying customers only seems counterproductive.

--

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.

[James Roper]

On Tue, Jun 24, 2014 at 8:21 AM, Eric Jain <eric...@gmail.com> wrote:

On Sun, Jun 22, 2014 at 11:21 PM, James Roper <james...@typesafe.com> wrote:
> I don't think there was anything deleted from 2.3 that wasn't deprecated in
> 2.2, if you have an example, please let us know.

Was minification of (non-rjs) js assets deprecated in 2.2?

No, but it wasn't really removed in Play 2.3.0, you can now get this functionality through the sbt-uglify plugin, just like all other sbt-web functionality:

https://github.com/sbt/sbt-uglify

We intentionally left doing this till after we released 2.3.0, mainly because we wanted to focus on quality before 2.3.0 was released.  After releasing Play 2.3.0, it was the first thing we worked on, and now the feature is there again.  This is one of the nice things about sbt-web, features like this are no longer tied to Play releases.

> Somehow, we have to find a way to differentiate between our paid
> subscription and the open source offerings, if we give identical service to
> both our paying customers and the open source community, then no one

> in their right mind would become a paying customer [...]

The incentive to be a paying customer is usually to have more reliable
support than the mailing list can provide; making bugfix releases
available to paying customers only seems counterproductive.

Bugfix releases are available to the community.  The question is not whether they are available, the question is what we backport - backporting anything to stable branches (including bugfixes) is always a risk, and takes time away from other things.  Immediately after a major release is released, we tend to backport a lot more, since the master and stable branch are very similar, so the risk is minimal - over time we backport less and less, especially given that often a non trivial amount of work is required to backport, and this requires very careful testing.  So generally, we prefer to be conservative with what we backport for the community, but for paying customers, we can afford to spend the extra time validating and testing the fixes we backport.

 

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

[Eric Jain]

On Mon, Jun 23, 2014 at 10:57 PM, James Roper <ja...@typesafe.com> wrote:
> After releasing Play 2.3.0, it was the first thing we worked on, and now the
> feature is there again.

I know, and sbt-web looks great, but this does underscore the point
that features sometimes come and go without much warning...

> backporting anything
> to stable branches (including bugfixes) is always a risk, and takes time
> away from other things.

Backporting to the stable branch might be less tedious if releases
were more frequent?

Companies often charge for patches etc for end-of-lifed versions, but
usually don't end-of-life the most current release weeks before the
next release...

Obviously it's up to you guys to figure out what business model works
for you, and I'm just another freeloader offering unsolicited advice
:-)

[tuxBurner]

Hi guys,

  i love the awesome play framework :) 

But release 2.3.0 is really confusing me. For what reason did you add the activator stuff ?

There is no reason which i see to do this, only pushing forward the activator product from typesafe. 

I think activator should be an additional feature, not the main thing to use and start play.

Cheers and keep on the good work :P 

[Chanan Braunstein]

Actually Activator for us at least has been very helpful. We have projects that are still 2.2.X and we have projects that are on 2.3. Without need to switch I can run the same activator and it will run either versions. Better yet, a developer that hasn't worked on 2.3 yet doesn't need to go install Play 2.3 anymore (if it were to exist in that form). He just needs to checkout the code and run activator and everything gets downloaded for him via sbt. Makes our life much easier.

[Megazord]

Same thing here. Activator help us (a lot) to handle different projects with different versions of play. Also, is it really a big deal to change from a command to another? We migrate in a matter of minutes and what took us more time was just change our provisioning tool to install activator instead of play. I understand that this change could annoy some people, but is it worth the amount of discussion we are having about it?

Just my 2 cents...

[James Roper]

It sounds like you're referring to the Activator UI. The activator UI is an additional feature, the activator command works just like the play command, ie "activator run" === "play run", and both of these just delegate to "sbt run".

--

[tuxBurner]

Hi James,

 i dont bother to use another command i dont care if it is play or activator. The only thing which confused me about switching from play to activator is that nobody really explained why :) 

Perhaps you should explain the benefits of using activator vs the old play command. And in my eyes the main benefit is not to have templates for play projects.

Cheers tuxBurner

[James Roper]

The reasoning is outlined here:

http://www.playframework.com/documentation/2.3.x/Highlights23

--

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.

[Christian]

Play 2.3 introduced breaking changes, so it would be appropriate to give it a new major version (3.0). I suggest to follow http://semver.org/. Version numbers are not a limited resource anymore! ;-)

Cheers
Christian

[Sander Sõnajalg]

On Wed, Jul 2, 2014 at 11:25 PM, Christian <chri...@helmbold.de> wrote:

Play 2.3 introduced breaking changes, so it would be appropriate to give it a new major version (3.0). I suggest to follow http://semver.org/. Version numbers are not a limited resource anymore! ;-)

Lets admit that one of the play guys just recently posted an explanation of their version numbering policy (which was $EPOCH.$MAJOR.$MINOR : ). I think it was even in the same thread.

I dare not to complain much as everything is nowadays so much better than it was during the Play 1.x days. And for me personally, 2.1.x --> 2.2.x was a much much problematic upgrade than 2.2.x --> 2.3.x. Mostly due to tight coupling between Play and SBT versioning. (SBT is my candidate for the tool with the worst learning curve ever... really wasted a ton of time there.)

But its also somewhat good that some guys complain a bit :) otherwise I guess the devs might get too much into the attitude of "oh i'll rename this public API method here, it looks much nicer this way" (r/SimpleResult/Result). But still, play2.x is a very nice framework. Big up.

Sander.

 

[Mathew Menalish]

Hi, I think u can help me to solve my issues. I am using Play 2.2.6. I am unable to create a executable jar. I  used dist command to package as a jar. But that jar does not contains lib folders for dependent Jars.

On Friday, May 30, 2014 at 6:25:44 PM UTC-5, 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

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Rich Dougherty]

On Wed, May 27, 2015 at 9:44 AM, Mathew Menalish <menal...@gmail.com> wrote:

Hi, I think u can help me to solve my issues. I am using Play 2.2.6. I am unable to create a executable jar. I  used dist command to package as a jar. But that jar does not contains lib folders for dependent Jars.

Hi Mathew

To make it easier for people to help you, you can ask your question in its own thread, e.g. "[2.2.6] creating executable JAR". You might also want to explain more about what you see in the JAR that's created.

– Rich

 

--

Rich Dougherty

Engineer, Typesafe, Inc

@richdougherty