Today's options for an easier migration path to Play 2

Question

I'm new to Scala and to Play, and I'm considering using them for a new project. I see the development on Play 2 is coming along nicely, although the stable version is still 1.x. And there are substantial differences between the two.

What I'm wondering is, if I start a Play 1.x project now, what options can I take that will ease migration to Play 2 in the future?

Namely:

• Play 2 uses Ebean as the default ORM, would you advise me to use it instead of Play 1.x's ORM (Hibernate)?
• What about the template system; anything I can do now to make it easier to migrate later on?
• What else will I have to worry about when I decide to port my app to Play 2 in the future?

Seasick

Answer 1

On the migration itself:

• There're plans to migrate the Groovy templates to Play 2 (I believe is work in progress). You can mitigate this is you start using Play 1.x with Scala, as the template system will be the Scala one.
• Changing from Hibernate to Ebean should be easy unless you use Hibernate-specific extensions.
• Configuration and some jobs (like @OnApplicationStart) may change, but this should be quite easy to port (just move them around).
• There will be changes to the way you access routes and assets, which may give you some extra work adapting code/templates.

In general it shouldn't be too complex, but as @lacy said, it depends on your deadlines and the project itself. If it's a critical project, to be finished before next March 2012, I would go with Play 1.x. If it's a less important project, which could be delayed, and that in any case won't be released before March 2012, try Play 2.0.

Seaborg

So, what you're saying is that, if i use the scala version of Play 1.x , my templates will be compatible with Play 2 out-of-the-box? – Seasick

And, regarding the ORM, the same applies as long as I stay away from hibernate extensions? – Seasick

@Filipe Correia if you use Scala, yes, templates seem to be compatible (it's beta, this may change, but nothing major for sure). On ORM, EBean is JPA compatible AFAIK, so you should have no issues. – Seaborg

Can you point me a good reference about that? I've meanwhile been reading stuff across the web that seem to indicate only groovy is allowed as a template language. But can't seem to find concrete examples – Seasick

@FilipeCorreia Here you have scala.playframework.org/documentation/scala-0.9.1/templates templates for 1.x In the Play 2.0 announcement they say they'll use scala templates in that release – Seaborg

Nice, it's mid march and 2.0 was just released ... right on time! Still, I'd like to see a walkthrough on how to migrate. – Crossland

Answer 2

I wouldn't even bother using Play2 on project for the moment. It still lacks some features and even if the development is going forward, I would stick with Play 1.2.x. Even if I have to admit it is tempting to try 2.0.

But I would never chose the in between solution, though. Starting in Play 1.2.x and trying to migrate toward 2.0.0. It is called Semantic Versionning. When the major number increases, there is no backward-compatibility. Meaning, you either use play 1.2.x or Play 2.0. Trying to migrate is going to cause you more stress, problems then you want to.

Inanition

Well, I guess it depends right? I hope there's a moment in which the benefits of Play 2 will outweigh the cost of porting from 1.x. My issue is, what can I do now to make sure that cost will be as low as possible, even if it's not negligible. – Seasick

Answer 3

This' all about your project's deadlines. Play2 is coming soon and some components already seem quite stable. So, if time allows, I would recommend you to use Play2. It recently has changed status to Beta. Several days ago Guillaume created a useful wiki on Github. You can also pay attention to the examples in the Play2 sources. And, as I understand, there will be no migration guidelines from Play1X to Play2.

Folsom

While jumping straight to Play 2 would certainly avoid any migration issues, all the team members will be new to Scala and to PLay, and I prefer to avoid any additional friction. So, I'm pretty sure I still want to use Play 1.x. for this project, but I want to minimize any migration effort that we will have when Play 2 is ready for production. Hence my question, which options/guidelines/conventions should I use to make that transition easier? – Seasick