Play 2.6 dropping support for Activator

[Greg Methvin]

Hi all,

As I’m sure many of you know, for the past few major releases the recommended way to get started with Play was using Activator. The original idea of Activator was to be a full featured environment for tutorials, training, and example projects across all of Lightbend’s technologies. Once you got started with Play you could of course just use SBT, but Activator provided a unified platform for getting started with Play and other reactive technologies.

Over time we’ve realized that Activator is not an ideal solution for most Play developers. If you just need a starter project, you shouldn’t need to download a 600MB+ application with a UI for that. There are far simpler and more robust solutions, including giter8 and simply cloning projects from GitHub and modifying them for your needs. We’ve also found that the tutorial aspects of Activator have not been used widely by the community, and most people seem to prefer web-based tutorials and blogs to learn about Play.

Since we believe those solutions are better for the majority of Play users, we’ve decided not to support Activator at all for the coming Play 2.6 release. We’ve updated the Play download page to describe the new methods you can use to get started.

So, how does this impact you?

Creating new applications:

SBT has added support for the sbt new command with support for giter8 templates. We’ve also internally developed an Example Code Service that packages sample projects for download on the Play website. The example projects actually include a local “sbt” executable so there is no need to download anything manually besides the example project.

You can see all Lightbend example projects on the Tech Hub. This also includes many tutorials and guides that were previously on Activator.

Creating and migrating templates:

If you are a template author, we recommend using giter8 instead. You can follow this guide for migrating your template to giter8.

Is activator still working?

You can still run the activator command to compile and package your applications, but we recommend that you adapt your workflow to use sbt directly. This should be easy to achieve since most activator commands (besides “ui” and “new”) just delegate to SBT.

More news about what will happen to existing activator templates will be coming soon.

Please let us know if you have any questions or feedback on this. Overall we believe this will be a strong positive change for the Play community and make it much easier to get started with Play.

--

Greg Methvin

Tech Lead - Play Framework

Lightbend, Inc.

[Anto Aravinth]

Hi,

Just yesterday I started working with Play. I felt the same with activator. I have worked with Grails before, its simplicity is just superb.

And also for the first time activator run took more than 15 minutes to run the application. Seriously that time I had a second thought about play!

Glad to see your taking this into consideration!

[Thibault Meyer]

The main issue with Play Framework, maybe is related to Scala or SBT itself, is the compilation time. A project with 200 scala class and 400 Java class took more than 10 minutes to compile, and of course if you editing a DB models, the project re-compile from scratch...

If I could give a good advice to SBT createor : please, implement distributed compilation like "distcc" (distcc is designed to speed up compilation by taking advantage of unused processing power on other computers. A machine with distcc installed can send code to be compiled across the network to a computer which has the distccd daemon and a compatible compiler installed).

[Igmar Palsenberg]

 

As I’m sure many of you know, for the past few major releases the recommended way to get started with Play was using Activator. The original idea of Activator was to be a full featured environment for tutorials, training, and example projects across all of Lightbend’s technologies. Once you got started with Play you could of course just use SBT, but Activator provided a unified platform for getting started with Play and other reactive technologies.

<start of rant>

While you're at it : Consider removing SBT. Really. It's a constant point of pain, and a cause of major loss of productivity. Some issues : 

1) Normal people don't understand it. To be somewhat productive, you need to grasp Scala. This results in copy & paste of random pieces of code until it works

2) It's "incremental compiler" is all but incremental. Compile X java and Y scala sources with 1 error, on the next run it compiles them all again.

3) It's dependency management is full of issues, often requiring a wipe of .ivy2

Really, I take GNU make or Maven over SBT any day.

</end of rant>

Igmar

 

[NOTiFY]

I like SBT and found the Activator very poor and all the so called "getting started" templates awful. I'm happy they're dropping Activator.

I first used Maven about 10 years ago, we had issues with the WiFi connection where I was working at the time and found Maven a pain compared to ANT which I'd been using from day one. 

I hated all the XML in Maven and find SBT a breeze to use. 

[Greg Methvin]

Hi Igmar,

Maven support is already planned for 3.0. It should already be technically possible to support other build systems now, since we've removed the dependency on SBT in runsupport, but a lot of work still needs to be done to provide the full Play experience on Maven. If you're interested in discussing this feel free to start another topic on the dev list.

Greg

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

For more options, visit https://groups.google.com/d/optout.

[Thibault Meyer]

Hi Greg,

great news. Actually, Play working with Gradle too, but related to Maven, Gradle is very slow.

[Will Sargent]

The funny thing is that Play itself is fairly huge, and yet Play itself doesn't take me 10 minutes to compile and test on my 2 core Macbook Pro from 2013.  I wonder how much is from play's aggressive use of submodules.

You can look at general compilation speed improvements here:

https://www.playframework.com/documentation/2.5.x/CompilationSpeed

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

--
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-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2089a012-b8b5-4e04-84be-e86330a89a0a%40googlegroups.com.

[Will Sargent]

There's a bunch of improvements to SBT in 0.13.14.

http://www.scala-sbt.org/0.13/docs/sbt-0.13-Tech-Previews.html

There's also a bunch of other options, although Lightbend doesn't officially support them:

Some people really enjoy https://github.com/coursier/coursier but this isn't a thing I have experience with.

There is a 3rd party Gradle plugin: https://docs.gradle.org/current/userguide/play_plugin.html -- I've been using this in some of my local projects and it seems to work well, but I have not personally seen huge / extensively modified Play gradle projects in the field.

There is also a 3rd party Maven plugin: https://github.com/play2-maven-plugin/play2-maven-plugin which I have not used.

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

On Wed, Mar 29, 2017 at 1:09 AM, Igmar Palsenberg <ig...@palsenberg.com> wrote:

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

[Marc Lisevich]

And that is why I could have used a license.

[Manabu Tokunaga]

I second Tiabault on the compilation time issue.

I switch between C# MVC and Play in my work. C# is a breeze, it compiles fast and I am up and running with a single line change in just a few seconds.

When I change one line of code in Play (actually even one letter in my code), it often results in iterative compile starting with 60 or more Scala or Java files. Then after that's done, it often generates more compiles. This result often in 2-5 minutes wait, and I have a relatively small project consisting no more than 100 files.

We can be told, our SBT is not configured right, or we could be missing Spring. But there is no easy way to find out what's causing this enormous waste of time, and Googling for this answer, there is not much out there. It almost feels like people have accepted this as the norm.

I have looked into it and there are some tricks to cut this time down. For example, I can relax the name change rules. That makes it really fast, but result in some strange side-effect, making it non-usable.

Another area that it is consuming a lot of time is the dependency check time. I can use the offline mode and also it makes the compile time significantly shorter but, again, with some strange side-effects that I do not want to investigate further. I don't need to check this every single line change. Perhaps once a day or once a week would be great. 

I think Scala is great, Play is easy to understand, especially almost it mirrors everything I do in Microsoft MVC making the switching back/forth easier, and SBT, once I learn it, is much simpler to manage and more powerful. I welcome the move of decoupling the Activator. I almost never use it, and when I use it, it almost never runs right and the examples are mostly not maintained or do not run "out of the box."  

I am trying hard not to become the Java/Scala/SBT expert, and rather solve the real world problem by writing applications.

But with this much loss of productivity, I may be forced to move to Node or C# on Unix, both of which I can iterate our development a lot more in an hour.

[alex s]

вторник, 18 апреля 2017 г., 9:02:48 UTC+3 пользователь Manabu Tokunaga написал:

I have looked into it and there are some tricks to cut this time down. For example, I can relax the name change rules. That makes it really fast, but result in some strange side-effect, making it non-usable.

What do you mean exactly? I assume you aren't talking about name hashing, which is enabled by default.
 

Another area that it is consuming a lot of time is the dependency check time. I can use the offline mode and also it makes the compile time significantly shorter but, again, with some strange side-effects that I do not want to investigate further.

Try https://github.com/coursier/coursier.

[Manabu Tokunaga]

Alex,

 

Thank you for the tips. Yes, definitely I’ve tried to mean the Name Hashing rules. There was a post about it I found a while ago. We’ve tried it. It worked mostly but at some point the code compiled but the app did not run quite right, as I recall.

 

I will now look into https://github.com/coursier/coursier it should help the lookup time significantly during the build and report back my experience.

--
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/NeMD04W6bN4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/ed4f10c8-880a-4b2f-9cb2-c9c2c9879b96%40googlegroups.com.

[Will Sargent]

On Monday, April 17, 2017 at 11:02:48 PM UTC-7, Manabu Tokunaga wrote:

I second Tiabault on the compilation time issue.

I switch between C# MVC and Play in my work. C# is a breeze, it compiles fast and I am up and running with a single line change in just a few seconds.

When I change one line of code in Play (actually even one letter in my code), it often results in iterative compile starting with 60 or more Scala or Java files. Then after that's done, it often generates more compiles. This result often in 2-5 minutes wait, and I have a relatively small project consisting no more than 100 files.

We can be told, our SBT is not configured right, or we could be missing Spring. But there is no easy way to find out what's causing this enormous waste of time, and Googling for this answer, there is not much out there. It almost feels like people have accepted this as the norm.

The problem is that without looking at the project in total, it's really hard to figure out what's going on.  There have been issues in the past where the play-file-watch service was running particularly slow because it was polling several thousand generated files in a single directory, for example.  This is the sort of thing we handle as part of a Lightbend subscription, where there are NDAs in place and we can dig into it more.

Generally speaking, you can look at sar and iostat to get an overall sense of where your IO is happening, and use sbt debug logging to get a sense of your overall compilation graph.  

http://www.brendangregg.com/USEmethod/use-linux.html

I'd also recommend using an Artifactory proxy. Artifactory 5 is pretty easy to set up -- you set up the remote repositories and aggregate them into a virtual repository and then set up .sbt/repositories and a publishTo task.

[Sahil]

Hi Greg,

Will the activator be still supported for existing productions services. We have 100s of services in production and we don't have any plan to migrate the services to latest version soon due to number of constraints.

Play 2.6 dropping support for Activator -

Will we be able to build and upgrade the services after the EOL(2017) for existing services or we need to migrate all our services before end of 2017?

Thanks

[Igmar Palsenberg]

 

Will the activator be still supported for existing productions services. We have 100s of services in production and we don't have any plan to migrate the services to latest version soon due to number of constraints.

Play 2.6 dropping support for Activator -

Will we be able to build and upgrade the services after the EOL(2017) for existing services or we need to migrate all our services before end of 2017?

activator is simply a layer on top of sbt, so I really don't see the issue here. Just replace it with sbt, and all should be fine.

Igmar 

[Patrick Li]

I don't use activator much, so glad to hear that no need to download the 600+MB package anymore :)

1) Normal people don't understand it. To be somewhat productive, you need to grasp Scala. This results in copy & paste of random pieces of code until it works
2) It's "incremental compiler" is all but incremental. Compile X java and Y scala sources with 1 error, on the next run it compiles them all again.
3) It's dependency management is full of issues, often requiring a wipe of .ivy2

Could not agree more with you on these, Igmar. SBT is one of the biggest bane for me, for the above reasons. I cringe every time I have to tell people about it, making it somewhat a "harder sell" for Play.

I am glad to hear plan/progress is being made to use Maven (or another build tool alternative). Problem with SBT, other than its extreme steep learning curve (and I thought Maven was hard when I first started), is some cloud build tool vendors do not even support or have it as an option, making devops pipeline harder than it needs to be.

[Rich Dougherty]

Hi Sahil

Igmar's right about Activator being a wrapper around to sbt. The main thing Activator supported that sbt didn't was creating new projects from templates and a browser based "IDE". The template part at least is now supported by sbt: http://www.scala-sbt.org/0.13/docs/sbt-new-and-Templates.html. At runtime sbt and Activator are identical, so you should be fine for production.

Cheers

Rich

--

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

For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Lightbend, Inc

@richdougherty