Since 2007, we have been working on making Java web application development easier. Play started as an internal project at Zenexity and was heavily influenced by our way of doing Web projects: focusing on developer productivity, respecting Web architecture, and using from the start a fresh approach to packaging conventions - breaking where it made sense the so-called JEE best practices.
In 2009, we decided to share these ideas with the community as an open source project. The immediate feedback was extremely positive and the project gained a lot of traction. Today - after two years of active development - Play has several versions, an animated community of 3,000 people, with a growing number of applications running in production all over the globe.
Opening a project to the world certainly means more feedback, but it also means discovering and learning about new use cases, requiring features and un-earthing bugs that we were not specifically considered in the original design and assumptions. During the two years of work on Play as an open source project we have worked to fix all of these kind of issues, as well as to integrate new features to support a wider range of scenarios. As the project has grown, we have learned a lot from our community and from our own experience - using Play in more and more complex and varied projects.
In the meantime, technology and the Web have continued to evolve. The Web has become the central point of all applications. HTML, CSS and Javascript technologies have evolved quickly - making it almost impossible for a server side framework to follow. The whole Web architecture is fast moving towards real-time, and the emerging requirements of today's project profiles means SQL no longer works as the exclusive datastore technology. At the programming languages level we've witnessed some monumental changes with several JVM languages, including Scala, gaining popularity.
That's why we think it's now time to move on, and to consider the next major version of Play. Welcome Play 2.0!
Native support for Java and Scala ---------------------------------
In Play 1.1, we started exploring the possibility of using the Scala programming language for writing Play applications. We initially introduced this work as an external module to be able to experiment freely without impacting the framework itself.
Properly integrating Scala into a Java-based framework is not trivial. Considering Scala’s compatibility with Java, one can quickly achieve a first naive integration that simply uses Scala’s syntax instead of Java’s. This, however, is certainly not the optimal way of using the language. Scala is a mix of true object orientation with functional programming. Leveraging the full power of Scala requires rethinking most of the framework’s APIs. After several versions we now have a clean Scala module that allows the use of most of Play's features from Scala, in a Scala-ish manner.
Now, we are reaching the limits of what we can do with Scala support as a separate module. Initial design choices we made in Play 1.x, relying heavily on Java reflection API and byte code manipulation, have made it harder to progress without completely rethinking some essential parts of Play’s internals. Meanwhile, we have created several awesome components for the Scala module, like the new type-safe template engine and the brand new SQL access component Anorm. So we have decided that, to fully unleash the power of Scala with Play, we are moving Scala support from a separate module to the core of Play 2.0, which will be designed from the beginning to natively support Scala as a programming language.
Java, on the other hand, is certainly not getting any less support from Play 2.0; quite the contrary. The Play 2.0 build provides us with an opportunity to enhance the development experience for Java developers. Backed by our experience throughout the project we have a clear idea of what we need to achieve and what mistakes we have to avoid.
Powerful build system ---------------------
From the beginning we have chosen a fresh way to run, compile and deploy Play applications. At the time it may have looked like an esoteric design - but it was crucial to providing an asynchronous HTTP API instead of the standard Servlet API, short feedback cycles through live compilation and reloading of source code during development, and promoting a fresh packaging approach. Consequently, It was difficult to make Play follow the standard JEE conventions.
Today, this idea of container-less deployment is more and more accepted in the Java world. It's a design choice that has allowed the Play framework to run natively on platforms like Heroku, which introduced a model that we consider the future of Java applications deployment on elastic PaaS platforms.
Existing Java build systems, however, were not flexible enough to support this new approach. Since we wanted to provide straightforward tools to run and deploy Play applications, in Play 1.x we created a collection of Python scripts to handle all build and deployment related tasks.
But developers using Play for more enterprise-scale projects, which require build process customization and integration with their existing company build systems, were a bit lost. The Python scripts we provide with Play 1.x are in no way a fully featured build system and are not easily customizable. That's why we've decided to go for a more powerful build system for Play 2.0.
As we need a modern build tool, flexible enough to support Play original conventions and able to build Java and Scala projects, we have chosen to integrate SBT in Play 2.0. This, however, should not scare existing Play users who are happy with the simplicity of Play build. We are leveraging the same simple play new, run, start experience on top of an extensible model: Play 2.0 will come with a preconfigured build script that will just work for most users. On the other hand, if you need to change the way your application is built, deployed, etc., a Play project being a standard SBT project will hand you all the power to customize and adapt it to your special needs. This also mean better integration with Maven projects out of the box, the ability to package and publish your project as a simple set of jar files to any repository, and especially live compiling and reloading at development time of any depended project even for standard Java or Scala libraries projects.
Focused on type safety ----------------------
One benefit of using Java as programming language for writing Play applications is that the Java compiler can check certain parts of your code. This is not only useful for detecting mistakes early in the development process, but it also makes it a lot easier to work on large projects with a lot developers involved.
Adding Scala to the mix for Play 2.0, we will clearly benefit from even stronger compiler guarantees - but that’s not enough. In Play 1.x, the template system is dynamic, based on the Groovy language, and the compiler can’t do much for you. As a result, errors in templates can only be detected at runtime. The same goes for verification of glue code with controllers.
We really want to push further this idea of having Play check most of your code at compilation time in the 2.0 version. Accordingly, we have decided to use the Scala based template engine as the default for Play applications - even for developers using Java as the main programming language. This doesn't mean that you have to become a Scala expert to write templates in Play 2.0, just like you were not really required to know Groovy to write templates in Play 1.x. Scala will be mainly used to navigate your object graph in order to display relevant information with a syntax that is very close to the Java one. However if you want to unleash the power of Scala to write advanced templates abstractions, you will quickly discover how Scala, being expression oriented and functional, is a perfect fit for a template engine.
And that's not only true for the template engine: the routing system will also be fully type-checked. Play 2.0 will check all your routes' descriptions, and verify that the everything is coherent, including the reverse routing part.
As a nice side effect, being fully compiled, the templates and route files will be easier to package and reuse and you can expect high performance gain on these parts at runtime.
Built for asynchronism ----------------------
Today's web applications are integrating more concurrent realtime data, so web frameworks need to support a full asynchronous HTTP programming model. Play 1.x was initially designed to handle classic Web applications with many short lived requests. But now, the event model is the way to go for persistent connections - though comet, long-polling and WebSockets.
Play 1.2 already provides great asynchronous HTTP support and WebScokets using continuations. Play 2.0 will be architected from the start under the assumption that every request is potentially long living. We want, for instance, to generalize Controller and WebsocketController concepts into one single simple model that fits all needs.
But that’s not all: we also need a powerful way to schedule and run long running tasks. Although the original Play 1.0 Jobs model was introduced for this, we really need something more powerful and robust. The Actor based model is unquestionably the best model today to handle highly concurrent systems, and the best implementation of that model available for both Java and Scala is Akka - so it's going in. We will be introducing native Akka support for Play applications, making it possible to write highly distributed systems.
Datastore and Model integration -------------------------------
Datastore is no longer synonymous with "SQL database", and it probably never was. A lot of interesting models of datastores are becoming popular, providing different properties for different
...
that sound like a good new direction for play. Would be great to have
the possibility to use the Scala-Template right now in a java-play-
project. Perhaps someone can show how this is possible. This enables
to avoid a migration of the templates.
2 question are still open to me:
1. Will the new framework mainly developed in Scala? I think this is
an important issue, because at the moment it's really easy for an
experienced java developer to analyze the code and create patches. How
will it be in the future? In other words, will you try to write as
much code as possible in Java and use only Scala where necessary or
the other way around?
2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
in the future?
Wish you great luck and a quick progress on Play 2.0. A beta at the
end of the year sounds great to me.
Niels
On 7 Sep., 11:39, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> Since 2007, we have been working on making Java web application
> development easier. Play started as an internal project at Zenexity
> and was heavily influenced by our way of doing Web projects: focusing
> on developer productivity, respecting Web architecture, and using from
> the start a fresh approach to packaging conventions - breaking where
> it made sense the so-called JEE best practices.
> In 2009, we decided to share these ideas with the community as an open
> source project. The immediate feedback was extremely positive and the
> project gained a lot of traction. Today - after two years of active
> development - Play has several versions, an animated community of
> 3,000 people, with a growing number of applications running in
> production all over the globe.
> Opening a project to the world certainly means more feedback, but it
> also means discovering and learning about new use cases, requiring
> features and un-earthing bugs that we were not specifically considered
> in the original design and assumptions. During the two years of work
> on Play as an open source project we have worked to fix all of these
> kind of issues, as well as to integrate new features to support a
> wider range of scenarios. As the project has grown, we have learned a
> lot from our community and from our own experience - using Play in
> more and more complex and varied projects.
> In the meantime, technology and the Web have continued to evolve. The
> Web has become the central point of all applications. HTML, CSS and
> Javascript technologies have evolved quickly - making it almost
> impossible for a server side framework to follow. The whole Web
> architecture is fast moving towards real-time, and the emerging
> requirements of today's project profiles means SQL no longer works as
> the exclusive datastore technology. At the programming languages level
> we've witnessed some monumental changes with several JVM languages,
> including Scala, gaining popularity.
> That's why we think it's now time to move on, and to consider the next
> major version of Play. Welcome Play 2.0!
> Native support for Java and Scala
> ---------------------------------
> In Play 1.1, we started exploring the possibility of using the Scala
> programming language for writing Play applications. We initially
> introduced this work as an external module to be able to experiment
> freely without impacting the framework itself.
> Properly integrating Scala into a Java-based framework is not trivial.
> Considering Scala’s compatibility with Java, one can quickly achieve a
> first naive integration that simply uses Scala’s syntax instead of
> Java’s. This, however, is certainly not the optimal way of using the
> language. Scala is a mix of true object orientation with functional
> programming. Leveraging the full power of Scala requires rethinking
> most of the framework’s APIs. After several versions we now have a
> clean Scala module that allows the use of most of Play's features from
> Scala, in a Scala-ish manner.
> Now, we are reaching the limits of what we can do with Scala support
> as a separate module. Initial design choices we made in Play 1.x,
> relying heavily on Java reflection API and byte code manipulation,
> have made it harder to progress without completely rethinking some
> essential parts of Play’s internals. Meanwhile, we have created
> several awesome components for the Scala module, like the new
> type-safe template engine and the brand new SQL access component
> Anorm. So we have decided that, to fully unleash the power of Scala
> with Play, we are moving Scala support from a separate module to the
> core of Play 2.0, which will be designed from the beginning to
> natively support Scala as a programming language.
> Java, on the other hand, is certainly not getting any less support
> from Play 2.0; quite the contrary. The Play 2.0 build provides us with
> an opportunity to enhance the development experience for Java
> developers. Backed by our experience throughout the project we have a
> clear idea of what we need to achieve and what mistakes we have to
> avoid.
> Powerful build system
> ---------------------
> From the beginning we have chosen a fresh way to run, compile and
> deploy Play applications. At the time it may have looked like an
> esoteric design - but it was crucial to providing an asynchronous HTTP
> API instead of the standard Servlet API, short feedback cycles through
> live compilation and reloading of source code during development, and
> promoting a fresh packaging approach. Consequently, It was difficult
> to make Play follow the standard JEE conventions.
> Today, this idea of container-less deployment is more and more
> accepted in the Java world. It's a design choice that has allowed the
> Play framework to run natively on platforms like Heroku, which
> introduced a model that we consider the future of Java applications
> deployment on elastic PaaS platforms.
> Existing Java build systems, however, were not flexible enough to
> support this new approach. Since we wanted to provide straightforward
> tools to run and deploy Play applications, in Play 1.x we created a
> collection of Python scripts to handle all build and deployment
> related tasks.
> But developers using Play for more enterprise-scale projects, which
> require build process customization and integration with their
> existing company build systems, were a bit lost. The Python scripts we
> provide with Play 1.x are in no way a fully featured build system and
> are not easily customizable. That's why we've decided to go for a more
> powerful build system for Play 2.0.
> As we need a modern build tool, flexible enough to support Play
> original conventions and able to build Java and Scala projects, we
> have chosen to integrate SBT in Play 2.0. This, however, should not
> scare existing Play users who are happy with the simplicity of Play
> build. We are leveraging the same simple play new, run, start
> experience on top of an extensible model: Play 2.0 will come with a
> preconfigured build script that will just work for most users. On the
> other hand, if you need to change the way your application is built,
> deployed, etc., a Play project being a standard SBT project will hand
> you all the power to customize and adapt it to your special needs.
> This also mean better integration with Maven projects out of the box,
> the ability to package and publish your project as a simple set of jar
> files to any repository, and especially live compiling and reloading
> at development time of any depended project even for standard Java or
> Scala libraries projects.
> Focused on type safety
> ----------------------
> One benefit of using Java as programming language for writing Play
> applications is that the Java compiler can check certain parts of your
> code. This is not only useful for detecting mistakes early in the
> development process, but it also makes it a lot easier to work on
> large projects with a lot developers involved.
> Adding Scala to the mix for Play 2.0, we will clearly benefit from
> even stronger compiler guarantees - but that’s not enough. In Play
> 1.x, the template system is dynamic, based on the Groovy language, and
> the compiler can’t do much for you. As a result, errors in templates
> can only be detected at runtime. The same goes for verification of
> glue code with controllers.
> We really want to push further this idea of having Play check most of
> your code at compilation time in the 2.0 version. Accordingly, we have
> decided to use the Scala based template engine as the default for Play
> applications - even for developers using Java as the main programming
> language. This doesn't mean that you have to become a Scala expert to
> write templates in Play 2.0, just like you were not really required to
> know Groovy to write templates in Play 1.x. Scala will be mainly used
> to navigate your object graph in order to display relevant information
> with a syntax that is very close to the Java one. However if you want
> to unleash the power of Scala to write advanced templates
> abstractions, you will quickly discover how Scala, being expression
> oriented and functional, is a perfect fit for a template engine.
> And that's not only true for the template engine: the routing system
> will also be fully type-checked. Play 2.0 will check all your routes'
> descriptions, and verify that the everything is coherent, including
> the reverse routing part.
> As a nice side effect, being fully compiled, the templates and route
> files will be easier to package and reuse and you can expect high
> performance gain on these parts at runtime.
> Built for asynchronism
> ----------------------
> Today's web applications are integrating more concurrent realtime
> data, so web
Moreover, when you foresee to integrate EBean, please also think about other frameworks (mine is siena as you may know) which will need to be integrated and do not wire everything too much tightly. In an ideal world, I would like to be able to remove completely EBean if I don't want it and replace it by Siena!
Anyway, I'm eager to see next steps and if you need help, don't hesitate to ask!
regards Pascal
On Wed, Sep 7, 2011 at 11:39 AM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
> Since 2007, we have been working on making Java web application > development easier. Play started as an internal project at Zenexity > and was heavily influenced by our way of doing Web projects: focusing > on developer productivity, respecting Web architecture, and using from > the start a fresh approach to packaging conventions - breaking where > it made sense the so-called JEE best practices.
> In 2009, we decided to share these ideas with the community as an open > source project. The immediate feedback was extremely positive and the > project gained a lot of traction. Today - after two years of active > development - Play has several versions, an animated community of > 3,000 people, with a growing number of applications running in > production all over the globe.
> Opening a project to the world certainly means more feedback, but it > also means discovering and learning about new use cases, requiring > features and un-earthing bugs that we were not specifically considered > in the original design and assumptions. During the two years of work > on Play as an open source project we have worked to fix all of these > kind of issues, as well as to integrate new features to support a > wider range of scenarios. As the project has grown, we have learned a > lot from our community and from our own experience - using Play in > more and more complex and varied projects.
> In the meantime, technology and the Web have continued to evolve. The > Web has become the central point of all applications. HTML, CSS and > Javascript technologies have evolved quickly - making it almost > impossible for a server side framework to follow. The whole Web > architecture is fast moving towards real-time, and the emerging > requirements of today's project profiles means SQL no longer works as > the exclusive datastore technology. At the programming languages level > we've witnessed some monumental changes with several JVM languages, > including Scala, gaining popularity.
> That's why we think it's now time to move on, and to consider the next > major version of Play. Welcome Play 2.0!
> Native support for Java and Scala > ---------------------------------
> In Play 1.1, we started exploring the possibility of using the Scala > programming language for writing Play applications. We initially > introduced this work as an external module to be able to experiment > freely without impacting the framework itself.
> Properly integrating Scala into a Java-based framework is not trivial. > Considering Scala’s compatibility with Java, one can quickly achieve a > first naive integration that simply uses Scala’s syntax instead of > Java’s. This, however, is certainly not the optimal way of using the > language. Scala is a mix of true object orientation with functional > programming. Leveraging the full power of Scala requires rethinking > most of the framework’s APIs. After several versions we now have a > clean Scala module that allows the use of most of Play's features from > Scala, in a Scala-ish manner.
> Now, we are reaching the limits of what we can do with Scala support > as a separate module. Initial design choices we made in Play 1.x, > relying heavily on Java reflection API and byte code manipulation, > have made it harder to progress without completely rethinking some > essential parts of Play’s internals. Meanwhile, we have created > several awesome components for the Scala module, like the new > type-safe template engine and the brand new SQL access component > Anorm. So we have decided that, to fully unleash the power of Scala > with Play, we are moving Scala support from a separate module to the > core of Play 2.0, which will be designed from the beginning to > natively support Scala as a programming language.
> Java, on the other hand, is certainly not getting any less support > from Play 2.0; quite the contrary. The Play 2.0 build provides us with > an opportunity to enhance the development experience for Java > developers. Backed by our experience throughout the project we have a > clear idea of what we need to achieve and what mistakes we have to > avoid.
> Powerful build system > ---------------------
> From the beginning we have chosen a fresh way to run, compile and > deploy Play applications. At the time it may have looked like an > esoteric design - but it was crucial to providing an asynchronous HTTP > API instead of the standard Servlet API, short feedback cycles through > live compilation and reloading of source code during development, and > promoting a fresh packaging approach. Consequently, It was difficult > to make Play follow the standard JEE conventions.
> Today, this idea of container-less deployment is more and more > accepted in the Java world. It's a design choice that has allowed the > Play framework to run natively on platforms like Heroku, which > introduced a model that we consider the future of Java applications > deployment on elastic PaaS platforms.
> Existing Java build systems, however, were not flexible enough to > support this new approach. Since we wanted to provide straightforward > tools to run and deploy Play applications, in Play 1.x we created a > collection of Python scripts to handle all build and deployment > related tasks.
> But developers using Play for more enterprise-scale projects, which > require build process customization and integration with their > existing company build systems, were a bit lost. The Python scripts we > provide with Play 1.x are in no way a fully featured build system and > are not easily customizable. That's why we've decided to go for a more > powerful build system for Play 2.0.
> As we need a modern build tool, flexible enough to support Play > original conventions and able to build Java and Scala projects, we > have chosen to integrate SBT in Play 2.0. This, however, should not > scare existing Play users who are happy with the simplicity of Play > build. We are leveraging the same simple play new, run, start > experience on top of an extensible model: Play 2.0 will come with a > preconfigured build script that will just work for most users. On the > other hand, if you need to change the way your application is built, > deployed, etc., a Play project being a standard SBT project will hand > you all the power to customize and adapt it to your special needs. > This also mean better integration with Maven projects out of the box, > the ability to package and publish your project as a simple set of jar > files to any repository, and especially live compiling and reloading > at development time of any depended project even for standard Java or > Scala libraries projects.
> Focused on type safety > ----------------------
> One benefit of using Java as programming language for writing Play > applications is that the Java compiler can check certain parts of your > code. This is not only useful for detecting mistakes early in the > development process, but it also makes it a lot easier to work on > large projects with a lot developers involved.
> Adding Scala to the mix for Play 2.0, we will clearly benefit from > even stronger compiler guarantees - but that’s not enough. In Play > 1.x, the template system is dynamic, based on the Groovy language, and > the compiler can’t do much for you. As a result, errors in templates > can only be detected at runtime. The same goes for verification of > glue code with controllers.
> We really want to push further this idea of having Play check most of > your code at compilation time in the 2.0 version. Accordingly, we have > decided to use the Scala based template engine as the default for Play > applications - even for developers using Java as the main programming > language. This doesn't mean that you have to become a Scala expert to > write templates in Play 2.0, just like you were not really required to > know Groovy to write templates in Play 1.x. Scala will be mainly used > to navigate your object graph in order to display relevant information > with a syntax that is very close to the Java one. However if you want > to unleash the power of Scala to write advanced templates > abstractions, you will quickly discover how Scala, being expression > oriented and functional, is a perfect fit for a template engine.
> And that's not only true for the template engine: the routing system > will also be fully type-checked. Play 2.0 will check all your routes' > descriptions, and verify that the everything is coherent, including > the reverse routing part.
> As a nice side effect, being fully compiled, the templates and route > files will be easier to package and reuse and you can expect high > performance gain on these parts at runtime.
> Built for asynchronism > ----------------------
> Today's web applications are integrating more concurrent realtime > data, so web frameworks need to support a full asynchronous HTTP > programming model. Play 1.x was initially designed to handle classic > Web applications with many short lived requests. But now, the event > model is the way to go for persistent connections - though comet, > long-polling and WebSockets.
> Play 1.2 already provides great asynchronous HTTP support and > WebScokets using continuations. Play 2.0 will be architected from the > start under the assumption that every request is potentially long > living. We want, for instance, to
> Since 2007, we have been working on making Java web application > development easier. Play started as an internal project at Zenexity > and was heavily influenced by our way of doing Web projects: focusing > on developer productivity, respecting Web architecture, and using from > the start a fresh approach to packaging conventions - breaking where > it made sense the so-called JEE best practices.
> In 2009, we decided to share these ideas with the community as an open > source project. The immediate feedback was extremely positive and the > project gained a lot of traction. Today - after two years of active > development - Play has several versions, an animated community of > 3,000 people, with a growing number of applications running in > production all over the globe.
> Opening a project to the world certainly means more feedback, but it > also means discovering and learning about new use cases, requiring > features and un-earthing bugs that we were not specifically considered > in the original design and assumptions. During the two years of work > on Play as an open source project we have worked to fix all of these > kind of issues, as well as to integrate new features to support a > wider range of scenarios. As the project has grown, we have learned a > lot from our community and from our own experience - using Play in > more and more complex and varied projects.
> In the meantime, technology and the Web have continued to evolve. The > Web has become the central point of all applications. HTML, CSS and > Javascript technologies have evolved quickly - making it almost > impossible for a server side framework to follow. The whole Web > architecture is fast moving towards real-time, and the emerging > requirements of today's project profiles means SQL no longer works as > the exclusive datastore technology. At the programming languages level > we've witnessed some monumental changes with several JVM languages, > including Scala, gaining popularity.
> That's why we think it's now time to move on, and to consider the next > major version of Play. Welcome Play 2.0!
> Native support for Java and Scala > ---------------------------------
> In Play 1.1, we started exploring the possibility of using the Scala > programming language for writing Play applications. We initially > introduced this work as an external module to be able to experiment > freely without impacting the framework itself.
> Properly integrating Scala into a Java-based framework is not trivial. > Considering Scala’s compatibility with Java, one can quickly achieve a > first naive integration that simply uses Scala’s syntax instead of > Java’s. This, however, is certainly not the optimal way of using the > language. Scala is a mix of true object orientation with functional > programming. Leveraging the full power of Scala requires rethinking > most of the framework’s APIs. After several versions we now have a > clean Scala module that allows the use of most of Play's features from > Scala, in a Scala-ish manner.
> Now, we are reaching the limits of what we can do with Scala support > as a separate module. Initial design choices we made in Play 1.x, > relying heavily on Java reflection API and byte code manipulation, > have made it harder to progress without completely rethinking some > essential parts of Play’s internals. Meanwhile, we have created > several awesome components for the Scala module, like the new > type-safe template engine and the brand new SQL access component > Anorm. So we have decided that, to fully unleash the power of Scala > with Play, we are moving Scala support from a separate module to the > core of Play 2.0, which will be designed from the beginning to > natively support Scala as a programming language.
> Java, on the other hand, is certainly not getting any less support > from Play 2.0; quite the contrary. The Play 2.0 build provides us with > an opportunity to enhance the development experience for Java > developers. Backed by our experience throughout the project we have a > clear idea of what we need to achieve and what mistakes we have to > avoid.
> Powerful build system > ---------------------
> From the beginning we have chosen a fresh way to run, compile and > deploy Play applications. At the time it may have looked like an > esoteric design - but it was crucial to providing an asynchronous HTTP > API instead of the standard Servlet API, short feedback cycles through > live compilation and reloading of source code during development, and > promoting a fresh packaging approach. Consequently, It was difficult > to make Play follow the standard JEE conventions.
> Today, this idea of container-less deployment is more and more > accepted in the Java world. It's a design choice that has allowed the > Play framework to run natively on platforms like Heroku, which > introduced a model that we consider the future of Java applications > deployment on elastic PaaS platforms.
> Existing Java build systems, however, were not flexible enough to > support this new approach. Since we wanted to provide straightforward > tools to run and deploy Play applications, in Play 1.x we created a > collection of Python scripts to handle all build and deployment > related tasks.
> But developers using Play for more enterprise-scale projects, which > require build process customization and integration with their > existing company build systems, were a bit lost. The Python scripts we > provide with Play 1.x are in no way a fully featured build system and > are not easily customizable. That's why we've decided to go for a more > powerful build system for Play 2.0.
> As we need a modern build tool, flexible enough to support Play > original conventions and able to build Java and Scala projects, we > have chosen to integrate SBT in Play 2.0. This, however, should not > scare existing Play users who are happy with the simplicity of Play > build. We are leveraging the same simple play new, run, start > experience on top of an extensible model: Play 2.0 will come with a > preconfigured build script that will just work for most users. On the > other hand, if you need to change the way your application is built, > deployed, etc., a Play project being a standard SBT project will hand > you all the power to customize and adapt it to your special needs. > This also mean better integration with Maven projects out of the box, > the ability to package and publish your project as a simple set of jar > files to any repository, and especially live compiling and reloading > at development time of any depended project even for standard Java or > Scala libraries projects.
> Focused on type safety > ----------------------
> One benefit of using Java as programming language for writing Play > applications is that the Java compiler can check certain parts of your > code. This is not only useful for detecting mistakes early in the > development process, but it also makes it a lot easier to work on > large projects with a lot developers involved.
> Adding Scala to the mix for Play 2.0, we will clearly benefit from > even stronger compiler guarantees - but that’s not enough. In Play > 1.x, the template system is dynamic, based on the Groovy language, and > the compiler can’t do much for you. As a result, errors in templates > can only be detected at runtime. The same goes for verification of > glue code with controllers.
> We really want to push further this idea of having Play check most of > your code at compilation time in the 2.0 version. Accordingly, we have > decided to use the Scala based template engine as the default for Play > applications - even for developers using Java as the main programming > language. This doesn't mean that you have to become a Scala expert to > write templates in Play 2.0, just like you were not really required to > know Groovy to write templates in Play 1.x. Scala will be mainly used > to navigate your object graph in order to display relevant information > with a syntax that is very close to the Java one. However if you want > to unleash the power of Scala to write advanced templates > abstractions, you will quickly discover how Scala, being expression > oriented and functional, is a perfect fit for a template engine.
> And that's not only true for the template engine: the routing system > will also be fully type-checked. Play 2.0 will check all your routes' > descriptions, and verify that the everything is coherent, including > the reverse routing part.
> As a nice side effect, being fully compiled, the templates and route > files will be easier to package and reuse and you can expect high > performance gain on these parts at runtime.
> Built for asynchronism > ----------------------
> Today's web applications are integrating more concurrent realtime > data, so web frameworks need to support a full asynchronous HTTP > programming model. Play 1.x was initially designed to handle classic > Web applications with many short lived requests. But now, the event > model is the way to go for persistent connections - though comet, > long-polling and WebSockets.
> Play 1.2 already provides great asynchronous HTTP support and > WebScokets using continuations. Play 2.0 will be architected from the > start under the assumption that every request is potentially long > living. We want, for instance, to generalize Controller and > WebsocketController concepts into one single simple model that fits > all needs.
> But that’s not all: we also need a powerful way to schedule and run > long running tasks. Although the original Play 1.0 Jobs model was > introduced for this, we really need something more powerful and > robust. The Actor based model
> 1. Will the new framework mainly developed in Scala? I think this is > an important issue, because at the moment it's really easy for an > experienced java developer to analyze the code and create patches. How > will it be in the future? In other words, will you try to write as > much code as possible in Java and use only Scala where necessary or > the other way around?
Most part of the core (HTTP and asynchronous invocation handling) will be written in Scala, because it is really easier and more robust (avoiding mutable states in this part will just make it easier to debug and maintain).
But all the Java related API will be written in Java. Because we want to provide an idiomatic API for Java and not force Java developers to deal with Scala types. Also we want to have a clean Javadoc for the Java API.
> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module > in the future?
I don't think so, or perhaps as an external module for particular ORM. But trying to provide an unified CRUD module for all persistence engines we can imagine is way too difficult. Anyway I think that the current CRUD module is not flexible enough. It mainly solve the need of writing a lot of repetitive screens, but It think it can be solved with a better form/paginated list, tag components instead. But nothing is decided yet.
> that sound like a good new direction for play. Would be great to have > the possibility to use the Scala-Template right now in a java-play- > project. Perhaps someone can show how this is possible. This enables > to avoid a migration of the templates. > 2 question are still open to me:
> 1. Will the new framework mainly developed in Scala? I think this is > an important issue, because at the moment it's really easy for an > experienced java developer to analyze the code and create patches. How > will it be in the future? In other words, will you try to write as > much code as possible in Java and use only Scala where necessary or > the other way around?
> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module > in the future?
> Wish you great luck and a quick progress on Play 2.0. A beta at the > end of the year sounds great to me.
> Niels
> On 7 Sep., 11:39, Guillaume Bort <guillaume.b...@gmail.com> wrote: >> Hi everyone,
>> Since 2007, we have been working on making Java web application >> development easier. Play started as an internal project at Zenexity >> and was heavily influenced by our way of doing Web projects: focusing >> on developer productivity, respecting Web architecture, and using from >> the start a fresh approach to packaging conventions - breaking where >> it made sense the so-called JEE best practices.
>> In 2009, we decided to share these ideas with the community as an open >> source project. The immediate feedback was extremely positive and the >> project gained a lot of traction. Today - after two years of active >> development - Play has several versions, an animated community of >> 3,000 people, with a growing number of applications running in >> production all over the globe.
>> Opening a project to the world certainly means more feedback, but it >> also means discovering and learning about new use cases, requiring >> features and un-earthing bugs that we were not specifically considered >> in the original design and assumptions. During the two years of work >> on Play as an open source project we have worked to fix all of these >> kind of issues, as well as to integrate new features to support a >> wider range of scenarios. As the project has grown, we have learned a >> lot from our community and from our own experience - using Play in >> more and more complex and varied projects.
>> In the meantime, technology and the Web have continued to evolve. The >> Web has become the central point of all applications. HTML, CSS and >> Javascript technologies have evolved quickly - making it almost >> impossible for a server side framework to follow. The whole Web >> architecture is fast moving towards real-time, and the emerging >> requirements of today's project profiles means SQL no longer works as >> the exclusive datastore technology. At the programming languages level >> we've witnessed some monumental changes with several JVM languages, >> including Scala, gaining popularity.
>> That's why we think it's now time to move on, and to consider the next >> major version of Play. Welcome Play 2.0!
>> Native support for Java and Scala >> ---------------------------------
>> In Play 1.1, we started exploring the possibility of using the Scala >> programming language for writing Play applications. We initially >> introduced this work as an external module to be able to experiment >> freely without impacting the framework itself.
>> Properly integrating Scala into a Java-based framework is not trivial. >> Considering Scala’s compatibility with Java, one can quickly achieve a >> first naive integration that simply uses Scala’s syntax instead of >> Java’s. This, however, is certainly not the optimal way of using the >> language. Scala is a mix of true object orientation with functional >> programming. Leveraging the full power of Scala requires rethinking >> most of the framework’s APIs. After several versions we now have a >> clean Scala module that allows the use of most of Play's features from >> Scala, in a Scala-ish manner.
>> Now, we are reaching the limits of what we can do with Scala support >> as a separate module. Initial design choices we made in Play 1.x, >> relying heavily on Java reflection API and byte code manipulation, >> have made it harder to progress without completely rethinking some >> essential parts of Play’s internals. Meanwhile, we have created >> several awesome components for the Scala module, like the new >> type-safe template engine and the brand new SQL access component >> Anorm. So we have decided that, to fully unleash the power of Scala >> with Play, we are moving Scala support from a separate module to the >> core of Play 2.0, which will be designed from the beginning to >> natively support Scala as a programming language.
>> Java, on the other hand, is certainly not getting any less support >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with >> an opportunity to enhance the development experience for Java >> developers. Backed by our experience throughout the project we have a >> clear idea of what we need to achieve and what mistakes we have to >> avoid.
>> Powerful build system >> ---------------------
>> From the beginning we have chosen a fresh way to run, compile and >> deploy Play applications. At the time it may have looked like an >> esoteric design - but it was crucial to providing an asynchronous HTTP >> API instead of the standard Servlet API, short feedback cycles through >> live compilation and reloading of source code during development, and >> promoting a fresh packaging approach. Consequently, It was difficult >> to make Play follow the standard JEE conventions.
>> Today, this idea of container-less deployment is more and more >> accepted in the Java world. It's a design choice that has allowed the >> Play framework to run natively on platforms like Heroku, which >> introduced a model that we consider the future of Java applications >> deployment on elastic PaaS platforms.
>> Existing Java build systems, however, were not flexible enough to >> support this new approach. Since we wanted to provide straightforward >> tools to run and deploy Play applications, in Play 1.x we created a >> collection of Python scripts to handle all build and deployment >> related tasks.
>> But developers using Play for more enterprise-scale projects, which >> require build process customization and integration with their >> existing company build systems, were a bit lost. The Python scripts we >> provide with Play 1.x are in no way a fully featured build system and >> are not easily customizable. That's why we've decided to go for a more >> powerful build system for Play 2.0.
>> As we need a modern build tool, flexible enough to support Play >> original conventions and able to build Java and Scala projects, we >> have chosen to integrate SBT in Play 2.0. This, however, should not >> scare existing Play users who are happy with the simplicity of Play >> build. We are leveraging the same simple play new, run, start >> experience on top of an extensible model: Play 2.0 will come with a >> preconfigured build script that will just work for most users. On the >> other hand, if you need to change the way your application is built, >> deployed, etc., a Play project being a standard SBT project will hand >> you all the power to customize and adapt it to your special needs. >> This also mean better integration with Maven projects out of the box, >> the ability to package and publish your project as a simple set of jar >> files to any repository, and especially live compiling and reloading >> at development time of any depended project even for standard Java or >> Scala libraries projects.
>> Focused on type safety >> ----------------------
>> One benefit of using Java as programming language for writing Play >> applications is that the Java compiler can check certain parts of your >> code. This is not only useful for detecting mistakes early in the >> development process, but it also makes it a lot easier to work on >> large projects with a lot developers involved.
>> Adding Scala to the mix for Play 2.0, we will clearly benefit from >> even stronger compiler guarantees - but that’s not enough. In Play >> 1.x, the template system is dynamic, based on the Groovy language, and >> the compiler can’t do much for you. As a result, errors in templates >> can only be detected at runtime. The same goes for verification of >> glue code with controllers.
> Moreover, when you foresee to integrate EBean, please also think about other > frameworks (mine is siena as you may know) which will need to be integrated > and do not wire everything too much tightly. In an ideal world, I would like > to be able to remove completely EBean if I don't want it and replace it by > Siena!
It exactly what we count on. That's why, even if we provide a default ORM for Java to keep the fullstack aspect of Play, allowing users to create quickly web applications, we won't integrate it too much with the other parts of the framework. It is really important for us that we can use whatever persistence engine you want with Play 2.0, without need to hack it.
Please track the progress, and if you think that we make choice that could limit integration with other persistence engine, in particular Siena, tell us!
On Wed, Sep 7, 2011 at 12:27 PM, Pascal Voitot Dev
<pascal.voitot....@gmail.com> wrote: > Globally, this sounds good new directions...
> I have the same questions as Niels.
> Moreover, when you foresee to integrate EBean, please also think about other > frameworks (mine is siena as you may know) which will need to be integrated > and do not wire everything too much tightly. In an ideal world, I would like > to be able to remove completely EBean if I don't want it and replace it by > Siena!
> Anyway, I'm eager to see next steps and if you need help, don't hesitate to > ask!
> regards > Pascal
> On Wed, Sep 7, 2011 at 11:39 AM, Guillaume Bort <guillaume.b...@gmail.com> > wrote:
>> Hi everyone,
>> Since 2007, we have been working on making Java web application >> development easier. Play started as an internal project at Zenexity >> and was heavily influenced by our way of doing Web projects: focusing >> on developer productivity, respecting Web architecture, and using from >> the start a fresh approach to packaging conventions - breaking where >> it made sense the so-called JEE best practices.
>> In 2009, we decided to share these ideas with the community as an open >> source project. The immediate feedback was extremely positive and the >> project gained a lot of traction. Today - after two years of active >> development - Play has several versions, an animated community of >> 3,000 people, with a growing number of applications running in >> production all over the globe.
>> Opening a project to the world certainly means more feedback, but it >> also means discovering and learning about new use cases, requiring >> features and un-earthing bugs that we were not specifically considered >> in the original design and assumptions. During the two years of work >> on Play as an open source project we have worked to fix all of these >> kind of issues, as well as to integrate new features to support a >> wider range of scenarios. As the project has grown, we have learned a >> lot from our community and from our own experience - using Play in >> more and more complex and varied projects.
>> In the meantime, technology and the Web have continued to evolve. The >> Web has become the central point of all applications. HTML, CSS and >> Javascript technologies have evolved quickly - making it almost >> impossible for a server side framework to follow. The whole Web >> architecture is fast moving towards real-time, and the emerging >> requirements of today's project profiles means SQL no longer works as >> the exclusive datastore technology. At the programming languages level >> we've witnessed some monumental changes with several JVM languages, >> including Scala, gaining popularity.
>> That's why we think it's now time to move on, and to consider the next >> major version of Play. Welcome Play 2.0!
>> Native support for Java and Scala >> ---------------------------------
>> In Play 1.1, we started exploring the possibility of using the Scala >> programming language for writing Play applications. We initially >> introduced this work as an external module to be able to experiment >> freely without impacting the framework itself.
>> Properly integrating Scala into a Java-based framework is not trivial. >> Considering Scala’s compatibility with Java, one can quickly achieve a >> first naive integration that simply uses Scala’s syntax instead of >> Java’s. This, however, is certainly not the optimal way of using the >> language. Scala is a mix of true object orientation with functional >> programming. Leveraging the full power of Scala requires rethinking >> most of the framework’s APIs. After several versions we now have a >> clean Scala module that allows the use of most of Play's features from >> Scala, in a Scala-ish manner.
>> Now, we are reaching the limits of what we can do with Scala support >> as a separate module. Initial design choices we made in Play 1.x, >> relying heavily on Java reflection API and byte code manipulation, >> have made it harder to progress without completely rethinking some >> essential parts of Play’s internals. Meanwhile, we have created >> several awesome components for the Scala module, like the new >> type-safe template engine and the brand new SQL access component >> Anorm. So we have decided that, to fully unleash the power of Scala >> with Play, we are moving Scala support from a separate module to the >> core of Play 2.0, which will be designed from the beginning to >> natively support Scala as a programming language.
>> Java, on the other hand, is certainly not getting any less support >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with >> an opportunity to enhance the development experience for Java >> developers. Backed by our experience throughout the project we have a >> clear idea of what we need to achieve and what mistakes we have to >> avoid.
>> Powerful build system >> ---------------------
>> From the beginning we have chosen a fresh way to run, compile and >> deploy Play applications. At the time it may have looked like an >> esoteric design - but it was crucial to providing an asynchronous HTTP >> API instead of the standard Servlet API, short feedback cycles through >> live compilation and reloading of source code during development, and >> promoting a fresh packaging approach. Consequently, It was difficult >> to make Play follow the standard JEE conventions.
>> Today, this idea of container-less deployment is more and more >> accepted in the Java world. It's a design choice that has allowed the >> Play framework to run natively on platforms like Heroku, which >> introduced a model that we consider the future of Java applications >> deployment on elastic PaaS platforms.
>> Existing Java build systems, however, were not flexible enough to >> support this new approach. Since we wanted to provide straightforward >> tools to run and deploy Play applications, in Play 1.x we created a >> collection of Python scripts to handle all build and deployment >> related tasks.
>> But developers using Play for more enterprise-scale projects, which >> require build process customization and integration with their >> existing company build systems, were a bit lost. The Python scripts we >> provide with Play 1.x are in no way a fully featured build system and >> are not easily customizable. That's why we've decided to go for a more >> powerful build system for Play 2.0.
>> As we need a modern build tool, flexible enough to support Play >> original conventions and able to build Java and Scala projects, we >> have chosen to integrate SBT in Play 2.0. This, however, should not >> scare existing Play users who are happy with the simplicity of Play >> build. We are leveraging the same simple play new, run, start >> experience on top of an extensible model: Play 2.0 will come with a >> preconfigured build script that will just work for most users. On the >> other hand, if you need to change the way your application is built, >> deployed, etc., a Play project being a standard SBT project will hand >> you all the power to customize and adapt it to your special needs. >> This also mean better integration with Maven projects out of the box, >> the ability to package and publish your project as a simple set of jar >> files to any repository, and especially live compiling and reloading >> at development time of any depended project even for standard Java or >> Scala libraries projects.
>> Focused on type safety >> ----------------------
>> One benefit of using Java as programming language for writing Play >> applications is that the Java compiler can check certain parts of your >> code. This is not only useful for detecting mistakes early in the >> development process, but it also makes it a lot easier to work on >> large projects with a lot developers involved.
>> Adding Scala to the mix for Play 2.0, we will clearly benefit from >> even stronger compiler guarantees - but that’s not enough. In Play >> 1.x, the template system is dynamic, based on the Groovy language, and >> the compiler can’t do much for you. As a result, errors in templates >> can only be detected at runtime. The same goes for verification of >> glue code with controllers.
>> We really want to push further this idea of having Play check most of >> your code at compilation time in the 2.0 version. Accordingly, we have >> decided to use the Scala based template engine as the default for Play >> applications - even for developers using Java as the main programming >> language. This doesn't mean that you have to become a Scala expert to >> write templates in Play 2.0, just like you were not really required to >> know Groovy to write templates in Play 1.x. Scala will be mainly used >> to navigate your object graph in order to display relevant information >> with a syntax that is very close to the Java one. However if you want >> to unleash the power of Scala to write advanced templates >> abstractions, you will quickly discover how Scala, being expression >> oriented and functional, is a perfect fit for a
> > Moreover, when you foresee to integrate EBean, please also think about > other > > frameworks (mine is siena as you may know) which will need to be > integrated > > and do not wire everything too much tightly. In an ideal world, I would > like > > to be able to remove completely EBean if I don't want it and replace it > by > > Siena!
> It exactly what we count on. That's why, even if we provide a default > ORM for Java to keep the fullstack aspect of Play, allowing users to > create quickly web applications, we won't integrate it too much with > the other parts of the framework. It is really important for us that > we can use whatever persistence engine you want with Play 2.0, without > need to hack it.
great :)
> Please track the progress, and if you think that we make choice that > could limit integration with other persistence engine, in particular > Siena, tell us!
Yes now that Siena is near its final version 1.0.0 (just need mongoDB impl to definitely prove the design works), I will look at play2.0 a bit nearer and will tell you if I see any problems... Your scala evolution will certainly help me to develop the Siena4Scala also!
Pascal
On Wed, Sep 7, 2011 at 12:27 PM, Pascal Voitot Dev
> <pascal.voitot....@gmail.com> wrote: > > Globally, this sounds good new directions...
> > I have the same questions as Niels.
> > Moreover, when you foresee to integrate EBean, please also think about > other > > frameworks (mine is siena as you may know) which will need to be > integrated > > and do not wire everything too much tightly. In an ideal world, I would > like > > to be able to remove completely EBean if I don't want it and replace it > by > > Siena!
> > Anyway, I'm eager to see next steps and if you need help, don't hesitate > to > > ask!
> > regards > > Pascal
> > On Wed, Sep 7, 2011 at 11:39 AM, Guillaume Bort < > guillaume.b...@gmail.com> > > wrote:
> >> Hi everyone,
> >> Since 2007, we have been working on making Java web application > >> development easier. Play started as an internal project at Zenexity > >> and was heavily influenced by our way of doing Web projects: focusing > >> on developer productivity, respecting Web architecture, and using from > >> the start a fresh approach to packaging conventions - breaking where > >> it made sense the so-called JEE best practices.
> >> In 2009, we decided to share these ideas with the community as an open > >> source project. The immediate feedback was extremely positive and the > >> project gained a lot of traction. Today - after two years of active > >> development - Play has several versions, an animated community of > >> 3,000 people, with a growing number of applications running in > >> production all over the globe.
> >> Opening a project to the world certainly means more feedback, but it > >> also means discovering and learning about new use cases, requiring > >> features and un-earthing bugs that we were not specifically considered > >> in the original design and assumptions. During the two years of work > >> on Play as an open source project we have worked to fix all of these > >> kind of issues, as well as to integrate new features to support a > >> wider range of scenarios. As the project has grown, we have learned a > >> lot from our community and from our own experience - using Play in > >> more and more complex and varied projects.
> >> In the meantime, technology and the Web have continued to evolve. The > >> Web has become the central point of all applications. HTML, CSS and > >> Javascript technologies have evolved quickly - making it almost > >> impossible for a server side framework to follow. The whole Web > >> architecture is fast moving towards real-time, and the emerging > >> requirements of today's project profiles means SQL no longer works as > >> the exclusive datastore technology. At the programming languages level > >> we've witnessed some monumental changes with several JVM languages, > >> including Scala, gaining popularity.
> >> That's why we think it's now time to move on, and to consider the next > >> major version of Play. Welcome Play 2.0!
> >> Native support for Java and Scala > >> ---------------------------------
> >> In Play 1.1, we started exploring the possibility of using the Scala > >> programming language for writing Play applications. We initially > >> introduced this work as an external module to be able to experiment > >> freely without impacting the framework itself.
> >> Properly integrating Scala into a Java-based framework is not trivial. > >> Considering Scala’s compatibility with Java, one can quickly achieve a > >> first naive integration that simply uses Scala’s syntax instead of > >> Java’s. This, however, is certainly not the optimal way of using the > >> language. Scala is a mix of true object orientation with functional > >> programming. Leveraging the full power of Scala requires rethinking > >> most of the framework’s APIs. After several versions we now have a > >> clean Scala module that allows the use of most of Play's features from > >> Scala, in a Scala-ish manner.
> >> Now, we are reaching the limits of what we can do with Scala support > >> as a separate module. Initial design choices we made in Play 1.x, > >> relying heavily on Java reflection API and byte code manipulation, > >> have made it harder to progress without completely rethinking some > >> essential parts of Play’s internals. Meanwhile, we have created > >> several awesome components for the Scala module, like the new > >> type-safe template engine and the brand new SQL access component > >> Anorm. So we have decided that, to fully unleash the power of Scala > >> with Play, we are moving Scala support from a separate module to the > >> core of Play 2.0, which will be designed from the beginning to > >> natively support Scala as a programming language.
> >> Java, on the other hand, is certainly not getting any less support > >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with > >> an opportunity to enhance the development experience for Java > >> developers. Backed by our experience throughout the project we have a > >> clear idea of what we need to achieve and what mistakes we have to > >> avoid.
> >> Powerful build system > >> ---------------------
> >> From the beginning we have chosen a fresh way to run, compile and > >> deploy Play applications. At the time it may have looked like an > >> esoteric design - but it was crucial to providing an asynchronous HTTP > >> API instead of the standard Servlet API, short feedback cycles through > >> live compilation and reloading of source code during development, and > >> promoting a fresh packaging approach. Consequently, It was difficult > >> to make Play follow the standard JEE conventions.
> >> Today, this idea of container-less deployment is more and more > >> accepted in the Java world. It's a design choice that has allowed the > >> Play framework to run natively on platforms like Heroku, which > >> introduced a model that we consider the future of Java applications > >> deployment on elastic PaaS platforms.
> >> Existing Java build systems, however, were not flexible enough to > >> support this new approach. Since we wanted to provide straightforward > >> tools to run and deploy Play applications, in Play 1.x we created a > >> collection of Python scripts to handle all build and deployment > >> related tasks.
> >> But developers using Play for more enterprise-scale projects, which > >> require build process customization and integration with their > >> existing company build systems, were a bit lost. The Python scripts we > >> provide with Play 1.x are in no way a fully featured build system and > >> are not easily customizable. That's why we've decided to go for a more > >> powerful build system for Play 2.0.
> >> As we need a modern build tool, flexible enough to support Play > >> original conventions and able to build Java and Scala projects, we > >> have chosen to integrate SBT in Play 2.0. This, however, should not > >> scare existing Play users who are happy with the simplicity of Play > >> build. We are leveraging the same simple play new, run, start > >> experience on top of an extensible model: Play 2.0 will come with a > >> preconfigured build script that will just work for most users. On the > >> other hand, if you need to change the way your application is built, > >> deployed, etc., a Play project being a standard SBT project will hand > >> you all the power to customize and adapt it to your special needs. > >> This also mean better integration with Maven projects out of the box, > >> the ability to package and publish your project as a simple set of jar > >> files to any repository, and especially live compiling and reloading > >> at development time of any depended project even for standard Java or > >> Scala libraries projects.
> >> Focused on type safety > >> ----------------------
> >> One benefit of using Java as programming language for writing Play > >> applications is that the Java compiler can check certain parts of your > >> code. This is not only useful for detecting mistakes early in the > >> development process, but it also makes it a lot easier to work on > >> large projects with a lot developers involved.
> >> Adding Scala to the mix for Play 2.0, we will clearly benefit from > >> even stronger compiler guarantees - but that’s not enough. In Play > >> 1.x, the template system is dynamic, based on the Groovy language, and > >> the compiler can’t do much for you. As a result, errors in templates > >> can only be detected at runtime. The same goes for verification of > >> glue code with controllers.
> >> We really want to push further this idea of having Play check most of > >> your code at
Developing a Web framework like Play is a lot of work, and maintaining 2 different versions would be terribly difficult. It's already the case currently with the Scala module that is always behind the main framework.
We prefer to merge efforts to provide a single perfect framework that will support Scala and Java independently.
On Wed, Sep 7, 2011 at 12:34 PM, Bing Ran <bing....@gmail.com> wrote: > I kind of like having another pure Scala framework created that is a port of the current Play Java and let the current Play be pure Java.
> Bing
> 在 2011-9-7，下午5:39， Guillaume Bort 写道：
>> Hi everyone,
>> Since 2007, we have been working on making Java web application >> development easier. Play started as an internal project at Zenexity >> and was heavily influenced by our way of doing Web projects: focusing >> on developer productivity, respecting Web architecture, and using from >> the start a fresh approach to packaging conventions - breaking where >> it made sense the so-called JEE best practices.
>> In 2009, we decided to share these ideas with the community as an open >> source project. The immediate feedback was extremely positive and the >> project gained a lot of traction. Today - after two years of active >> development - Play has several versions, an animated community of >> 3,000 people, with a growing number of applications running in >> production all over the globe.
>> Opening a project to the world certainly means more feedback, but it >> also means discovering and learning about new use cases, requiring >> features and un-earthing bugs that we were not specifically considered >> in the original design and assumptions. During the two years of work >> on Play as an open source project we have worked to fix all of these >> kind of issues, as well as to integrate new features to support a >> wider range of scenarios. As the project has grown, we have learned a >> lot from our community and from our own experience - using Play in >> more and more complex and varied projects.
>> In the meantime, technology and the Web have continued to evolve. The >> Web has become the central point of all applications. HTML, CSS and >> Javascript technologies have evolved quickly - making it almost >> impossible for a server side framework to follow. The whole Web >> architecture is fast moving towards real-time, and the emerging >> requirements of today's project profiles means SQL no longer works as >> the exclusive datastore technology. At the programming languages level >> we've witnessed some monumental changes with several JVM languages, >> including Scala, gaining popularity.
>> That's why we think it's now time to move on, and to consider the next >> major version of Play. Welcome Play 2.0!
>> Native support for Java and Scala >> ---------------------------------
>> In Play 1.1, we started exploring the possibility of using the Scala >> programming language for writing Play applications. We initially >> introduced this work as an external module to be able to experiment >> freely without impacting the framework itself.
>> Properly integrating Scala into a Java-based framework is not trivial. >> Considering Scala’s compatibility with Java, one can quickly achieve a >> first naive integration that simply uses Scala’s syntax instead of >> Java’s. This, however, is certainly not the optimal way of using the >> language. Scala is a mix of true object orientation with functional >> programming. Leveraging the full power of Scala requires rethinking >> most of the framework’s APIs. After several versions we now have a >> clean Scala module that allows the use of most of Play's features from >> Scala, in a Scala-ish manner.
>> Now, we are reaching the limits of what we can do with Scala support >> as a separate module. Initial design choices we made in Play 1.x, >> relying heavily on Java reflection API and byte code manipulation, >> have made it harder to progress without completely rethinking some >> essential parts of Play’s internals. Meanwhile, we have created >> several awesome components for the Scala module, like the new >> type-safe template engine and the brand new SQL access component >> Anorm. So we have decided that, to fully unleash the power of Scala >> with Play, we are moving Scala support from a separate module to the >> core of Play 2.0, which will be designed from the beginning to >> natively support Scala as a programming language.
>> Java, on the other hand, is certainly not getting any less support >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with >> an opportunity to enhance the development experience for Java >> developers. Backed by our experience throughout the project we have a >> clear idea of what we need to achieve and what mistakes we have to >> avoid.
>> Powerful build system >> ---------------------
>> From the beginning we have chosen a fresh way to run, compile and >> deploy Play applications. At the time it may have looked like an >> esoteric design - but it was crucial to providing an asynchronous HTTP >> API instead of the standard Servlet API, short feedback cycles through >> live compilation and reloading of source code during development, and >> promoting a fresh packaging approach. Consequently, It was difficult >> to make Play follow the standard JEE conventions.
>> Today, this idea of container-less deployment is more and more >> accepted in the Java world. It's a design choice that has allowed the >> Play framework to run natively on platforms like Heroku, which >> introduced a model that we consider the future of Java applications >> deployment on elastic PaaS platforms.
>> Existing Java build systems, however, were not flexible enough to >> support this new approach. Since we wanted to provide straightforward >> tools to run and deploy Play applications, in Play 1.x we created a >> collection of Python scripts to handle all build and deployment >> related tasks.
>> But developers using Play for more enterprise-scale projects, which >> require build process customization and integration with their >> existing company build systems, were a bit lost. The Python scripts we >> provide with Play 1.x are in no way a fully featured build system and >> are not easily customizable. That's why we've decided to go for a more >> powerful build system for Play 2.0.
>> As we need a modern build tool, flexible enough to support Play >> original conventions and able to build Java and Scala projects, we >> have chosen to integrate SBT in Play 2.0. This, however, should not >> scare existing Play users who are happy with the simplicity of Play >> build. We are leveraging the same simple play new, run, start >> experience on top of an extensible model: Play 2.0 will come with a >> preconfigured build script that will just work for most users. On the >> other hand, if you need to change the way your application is built, >> deployed, etc., a Play project being a standard SBT project will hand >> you all the power to customize and adapt it to your special needs. >> This also mean better integration with Maven projects out of the box, >> the ability to package and publish your project as a simple set of jar >> files to any repository, and especially live compiling and reloading >> at development time of any depended project even for standard Java or >> Scala libraries projects.
>> Focused on type safety >> ----------------------
>> One benefit of using Java as programming language for writing Play >> applications is that the Java compiler can check certain parts of your >> code. This is not only useful for detecting mistakes early in the >> development process, but it also makes it a lot easier to work on >> large projects with a lot developers involved.
>> Adding Scala to the mix for Play 2.0, we will clearly benefit from >> even stronger compiler guarantees - but that’s not enough. In Play >> 1.x, the template system is dynamic, based on the Groovy language, and >> the compiler can’t do much for you. As a result, errors in templates >> can only be detected at runtime. The same goes for verification of >> glue code with controllers.
>> We really want to push further this idea of having Play check most of >> your code at compilation time in the 2.0 version. Accordingly, we have >> decided to use the Scala based template engine as the default for Play >> applications - even for developers using Java as the main programming >> language. This doesn't mean that you have to become a Scala expert to >> write templates in Play 2.0, just like you were not really required to >> know Groovy to write templates in Play 1.x. Scala will be mainly used >> to navigate your object graph in order to display relevant information >> with a syntax that is very close to the Java one. However if you want >> to unleash the power of Scala to write advanced templates >> abstractions, you will quickly discover how Scala, being expression >> oriented and functional, is a perfect fit for a template engine.
>> And that's not only true for the template engine: the routing system >> will also be fully type-checked. Play 2.0 will check all your routes' >> descriptions, and verify that the everything is coherent, including >> the reverse routing part.
>> As a nice side effect, being fully compiled, the templates and route >> files will be easier to package and reuse and you can expect high >> performance gain on these parts at runtime.
>> Built for asynchronism >> ----------------------
>> Today's web applications are integrating more concurrent realtime >> data, so web frameworks need to support a full asynchronous HTTP >> programming model. Play 1.x was initially designed to handle classic >> Web applications with many short lived requests. But now, the event >> model is the way to go for persistent connections - though comet, >> long-polling and WebSockets.
I agree with you... Now that I know better Scala (and love it more and more), I know that you can write the core in Scala and make it fully available to any Java application and provide some external full-Java APIs without any problem. The only drawback is for people who liked to modify the code and now they will need to know Scala. But anyway, I agree with you, maintaining 2 frameworks would be crazy!
pascal
On Wed, Sep 7, 2011 at 12:46 PM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
> Developing a Web framework like Play is a lot of work, and maintaining > 2 different versions would be terribly difficult. It's already the > case currently with the Scala module that is always behind the main > framework.
> We prefer to merge efforts to provide a single perfect framework that > will support Scala and Java independently.
> On Wed, Sep 7, 2011 at 12:34 PM, Bing Ran <bing....@gmail.com> wrote: > > I kind of like having another pure Scala framework created that is a port > of the current Play Java and let the current Play be pure Java.
> > Bing
> > 在 2011-9-7，下午5:39， Guillaume Bort 写道：
> >> Hi everyone,
> >> Since 2007, we have been working on making Java web application > >> development easier. Play started as an internal project at Zenexity > >> and was heavily influenced by our way of doing Web projects: focusing > >> on developer productivity, respecting Web architecture, and using from > >> the start a fresh approach to packaging conventions - breaking where > >> it made sense the so-called JEE best practices.
> >> In 2009, we decided to share these ideas with the community as an open > >> source project. The immediate feedback was extremely positive and the > >> project gained a lot of traction. Today - after two years of active > >> development - Play has several versions, an animated community of > >> 3,000 people, with a growing number of applications running in > >> production all over the globe.
> >> Opening a project to the world certainly means more feedback, but it > >> also means discovering and learning about new use cases, requiring > >> features and un-earthing bugs that we were not specifically considered > >> in the original design and assumptions. During the two years of work > >> on Play as an open source project we have worked to fix all of these > >> kind of issues, as well as to integrate new features to support a > >> wider range of scenarios. As the project has grown, we have learned a > >> lot from our community and from our own experience - using Play in > >> more and more complex and varied projects.
> >> In the meantime, technology and the Web have continued to evolve. The > >> Web has become the central point of all applications. HTML, CSS and > >> Javascript technologies have evolved quickly - making it almost > >> impossible for a server side framework to follow. The whole Web > >> architecture is fast moving towards real-time, and the emerging > >> requirements of today's project profiles means SQL no longer works as > >> the exclusive datastore technology. At the programming languages level > >> we've witnessed some monumental changes with several JVM languages, > >> including Scala, gaining popularity.
> >> That's why we think it's now time to move on, and to consider the next > >> major version of Play. Welcome Play 2.0!
> >> Native support for Java and Scala > >> ---------------------------------
> >> In Play 1.1, we started exploring the possibility of using the Scala > >> programming language for writing Play applications. We initially > >> introduced this work as an external module to be able to experiment > >> freely without impacting the framework itself.
> >> Properly integrating Scala into a Java-based framework is not trivial. > >> Considering Scala’s compatibility with Java, one can quickly achieve a > >> first naive integration that simply uses Scala’s syntax instead of > >> Java’s. This, however, is certainly not the optimal way of using the > >> language. Scala is a mix of true object orientation with functional > >> programming. Leveraging the full power of Scala requires rethinking > >> most of the framework’s APIs. After several versions we now have a > >> clean Scala module that allows the use of most of Play's features from > >> Scala, in a Scala-ish manner.
> >> Now, we are reaching the limits of what we can do with Scala support > >> as a separate module. Initial design choices we made in Play 1.x, > >> relying heavily on Java reflection API and byte code manipulation, > >> have made it harder to progress without completely rethinking some > >> essential parts of Play’s internals. Meanwhile, we have created > >> several awesome components for the Scala module, like the new > >> type-safe template engine and the brand new SQL access component > >> Anorm. So we have decided that, to fully unleash the power of Scala > >> with Play, we are moving Scala support from a separate module to the > >> core of Play 2.0, which will be designed from the beginning to > >> natively support Scala as a programming language.
> >> Java, on the other hand, is certainly not getting any less support > >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with > >> an opportunity to enhance the development experience for Java > >> developers. Backed by our experience throughout the project we have a > >> clear idea of what we need to achieve and what mistakes we have to > >> avoid.
> >> Powerful build system > >> ---------------------
> >> From the beginning we have chosen a fresh way to run, compile and > >> deploy Play applications. At the time it may have looked like an > >> esoteric design - but it was crucial to providing an asynchronous HTTP > >> API instead of the standard Servlet API, short feedback cycles through > >> live compilation and reloading of source code during development, and > >> promoting a fresh packaging approach. Consequently, It was difficult > >> to make Play follow the standard JEE conventions.
> >> Today, this idea of container-less deployment is more and more > >> accepted in the Java world. It's a design choice that has allowed the > >> Play framework to run natively on platforms like Heroku, which > >> introduced a model that we consider the future of Java applications > >> deployment on elastic PaaS platforms.
> >> Existing Java build systems, however, were not flexible enough to > >> support this new approach. Since we wanted to provide straightforward > >> tools to run and deploy Play applications, in Play 1.x we created a > >> collection of Python scripts to handle all build and deployment > >> related tasks.
> >> But developers using Play for more enterprise-scale projects, which > >> require build process customization and integration with their > >> existing company build systems, were a bit lost. The Python scripts we > >> provide with Play 1.x are in no way a fully featured build system and > >> are not easily customizable. That's why we've decided to go for a more > >> powerful build system for Play 2.0.
> >> As we need a modern build tool, flexible enough to support Play > >> original conventions and able to build Java and Scala projects, we > >> have chosen to integrate SBT in Play 2.0. This, however, should not > >> scare existing Play users who are happy with the simplicity of Play > >> build. We are leveraging the same simple play new, run, start > >> experience on top of an extensible model: Play 2.0 will come with a > >> preconfigured build script that will just work for most users. On the > >> other hand, if you need to change the way your application is built, > >> deployed, etc., a Play project being a standard SBT project will hand > >> you all the power to customize and adapt it to your special needs. > >> This also mean better integration with Maven projects out of the box, > >> the ability to package and publish your project as a simple set of jar > >> files to any repository, and especially live compiling and reloading > >> at development time of any depended project even for standard Java or > >> Scala libraries projects.
> >> Focused on type safety > >> ----------------------
> >> One benefit of using Java as programming language for writing Play > >> applications is that the Java compiler can check certain parts of your > >> code. This is not only useful for detecting mistakes early in the > >> development process, but it also makes it a lot easier to work on > >> large projects with a lot developers involved.
> >> Adding Scala to the mix for Play 2.0, we will clearly benefit from > >> even stronger compiler guarantees - but that’s not enough. In Play > >> 1.x, the template system is dynamic, based on the Groovy language, and > >> the compiler can’t do much for you. As a result, errors in templates > >> can only be detected at runtime. The same goes for verification of > >> glue code with controllers.
> >> We really want to push further this idea of having Play check most of > >> your code at compilation time in the 2.0 version. Accordingly, we have > >> decided to use the Scala based template engine as the default for Play > >> applications - even for developers using Java as the main programming > >> language. This doesn't mean that you have to become a Scala expert to > >> write templates in Play 2.0, just like you were not really required to > >> know Groovy to write templates in Play 1.x. Scala will be mainly used > >> to navigate your object graph in order to display relevant information > >> with a syntax that is very close to the Java one. However if you want > >> to unleash the power of Scala to write advanced templates > >> abstractions, you will quickly discover how Scala, being expression > >> oriented and functional, is a perfect fit for a template engine.
> >> And that's not only true for the template engine: the routing system
This is both good and bad news. While new and shiny stuff is always great, I guess nobody likes the idea of having a completely different Play framework. I hope you guys are able to define a clear migration path for 1.2.3. users that want to move to 2.0. Especially the ones like me that use the Scala plugin.
One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope that feature isn't planned for the 2.0 version only.
> This is both good and bad news. While new and shiny stuff is always great, I > guess nobody likes the idea of having a completely different Play framework. > I hope you guys are able to define a clear migration path for 1.2.3. users > that want to move to 2.0. Especially the ones like me that use the Scala > plugin.
If you are using the Scala module currently, the migration path to Play 2.0 will be easy. The most important change that will make migration to Play 2.0 difficult is the new type safe template engine. But if you are already using it it will be easy.
> One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope > that feature isn't planned for the 2.0 version only.
Problem is that Scala 2.9.0 breaks the Java reflection API (they done it for good reasons however). So migrating the Scala module to 2.9.x breaks almost everywhere it uses Java reflection API(binding, fixtures, etc.). It's almost impossible to migrate without rewriting these parts.
On Wed, Sep 7, 2011 at 1:08 PM, Hristo Deshev <hri...@deshev.com> wrote: > This is both good and bad news. While new and shiny stuff is always great, I > guess nobody likes the idea of having a completely different Play framework. > I hope you guys are able to define a clear migration path for 1.2.3. users > that want to move to 2.0. Especially the ones like me that use the Scala > plugin. > One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope > that feature isn't planned for the 2.0 version only. > Best, > Hristo
> -- > You received this message because you are subscribed to the Google Groups > "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
> Since 2007, we have been working on making Java web application > development easier. Play started as an internal project at Zenexity > and was heavily influenced by our way of doing Web projects: focusing > on developer productivity, respecting Web architecture, and using from > the start a fresh approach to packaging conventions - breaking where > it made sense the so-called JEE best practices.
> In 2009, we decided to share these ideas with the community as an open > source project. The immediate feedback was extremely positive and the > project gained a lot of traction. Today - after two years of active > development - Play has several versions, an animated community of > 3,000 people, with a growing number of applications running in > production all over the globe.
> Opening a project to the world certainly means more feedback, but it > also means discovering and learning about new use cases, requiring > features and un-earthing bugs that we were not specifically considered > in the original design and assumptions. During the two years of work > on Play as an open source project we have worked to fix all of these > kind of issues, as well as to integrate new features to support a > wider range of scenarios. As the project has grown, we have learned a > lot from our community and from our own experience - using Play in > more and more complex and varied projects.
> In the meantime, technology and the Web have continued to evolve. The > Web has become the central point of all applications. HTML, CSS and > Javascript technologies have evolved quickly - making it almost > impossible for a server side framework to follow. The whole Web > architecture is fast moving towards real-time, and the emerging > requirements of today's project profiles means SQL no longer works as > the exclusive datastore technology. At the programming languages level > we've witnessed some monumental changes with several JVM languages, > including Scala, gaining popularity.
> That's why we think it's now time to move on, and to consider the next > major version of Play. Welcome Play 2.0!
> Native support for Java and Scala > ---------------------------------
> In Play 1.1, we started exploring the possibility of using the Scala > programming language for writing Play applications. We initially > introduced this work as an external module to be able to experiment > freely without impacting the framework itself.
> Properly integrating Scala into a Java-based framework is not trivial. > Considering Scala’s compatibility with Java, one can quickly achieve a > first naive integration that simply uses Scala’s syntax instead of > Java’s. This, however, is certainly not the optimal way of using the > language. Scala is a mix of true object orientation with functional > programming. Leveraging the full power of Scala requires rethinking > most of the framework’s APIs. After several versions we now have a > clean Scala module that allows the use of most of Play's features from > Scala, in a Scala-ish manner.
> Now, we are reaching the limits of what we can do with Scala support > as a separate module. Initial design choices we made in Play 1.x, > relying heavily on Java reflection API and byte code manipulation, > have made it harder to progress without completely rethinking some > essential parts of Play’s internals. Meanwhile, we have created > several awesome components for the Scala module, like the new > type-safe template engine and the brand new SQL access component > Anorm. So we have decided that, to fully unleash the power of Scala > with Play, we are moving Scala support from a separate module to the > core of Play 2.0, which will be designed from the beginning to > natively support Scala as a programming language.
> Java, on the other hand, is certainly not getting any less support > from Play 2.0; quite the contrary. The Play 2.0 build provides us with > an opportunity to enhance the development experience for Java > developers. Backed by our experience throughout the project we have a > clear idea of what we need to achieve and what mistakes we have to > avoid.
> Powerful build system > ---------------------
> From the beginning we have chosen a fresh way to run, compile and > deploy Play applications. At the time it may have looked like an > esoteric design - but it was crucial to providing an asynchronous HTTP > API instead of the standard Servlet API, short feedback cycles through > live compilation and reloading of source code during development, and > promoting a fresh packaging approach. Consequently, It was difficult > to make Play follow the standard JEE conventions.
> Today, this idea of container-less deployment is more and more > accepted in the Java world. It's a design choice that has allowed the > Play framework to run natively on platforms like Heroku, which > introduced a model that we consider the future of Java applications > deployment on elastic PaaS platforms.
> Existing Java build systems, however, were not flexible enough to > support this new approach. Since we wanted to provide straightforward > tools to run and deploy Play applications, in Play 1.x we created a > collection of Python scripts to handle all build and deployment > related tasks.
> But developers using Play for more enterprise-scale projects, which > require build process customization and integration with their > existing company build systems, were a bit lost. The Python scripts we > provide with Play 1.x are in no way a fully featured build system and > are not easily customizable. That's why we've decided to go for a more > powerful build system for Play 2.0.
> As we need a modern build tool, flexible enough to support Play > original conventions and able to build Java and Scala projects, we > have chosen to integrate SBT in Play 2.0. This, however, should not > scare existing Play users who are happy with the simplicity of Play > build. We are leveraging the same simple play new, run, start > experience on top of an extensible model: Play 2.0 will come with a > preconfigured build script that will just work for most users. On the > other hand, if you need to change the way your application is built, > deployed, etc., a Play project being a standard SBT project will hand > you all the power to customize and adapt it to your special needs. > This also mean better integration with Maven projects out of the box, > the ability to package and publish your project as a simple set of jar > files to any repository, and especially live compiling and reloading > at development time of any depended project even for standard Java or > Scala libraries projects.
> Focused on type safety > ----------------------
> One benefit of using Java as programming language for writing Play > applications is that the Java compiler can check certain parts of your > code. This is not only useful for detecting mistakes early in the > development process, but it also makes it a lot easier to work on > large projects with a lot developers involved.
> Adding Scala to the mix for Play 2.0, we will clearly benefit from > even stronger compiler guarantees - but that’s not enough. In Play > 1.x, the template system is dynamic, based on the Groovy language, and > the compiler can’t do much for you. As a result, errors in templates > can only be detected at runtime. The same goes for verification of > glue code with controllers.
> We really want to push further this idea of having Play check most of > your code at compilation time in the 2.0 version. Accordingly, we have > decided to use the Scala based template engine as the default for Play > applications - even for developers using Java as the main programming > language. This doesn't mean that you have to become a Scala expert to > write templates in Play 2.0, just like you were not really required to > know Groovy to write templates in Play 1.x. Scala will be mainly used > to navigate your object graph in order to display relevant information > with a syntax that is very close to the Java one. However if you want > to unleash the power of Scala to write advanced templates > abstractions, you will quickly discover how Scala, being expression > oriented and functional, is a perfect fit for a template engine.
> And that's not only true for the template engine: the routing system > will also be fully type-checked. Play 2.0 will check all your routes' > descriptions, and verify that the everything is coherent, including > the reverse routing part.
> As a nice side effect, being fully compiled, the templates and route > files will be easier to package and reuse and you can expect high > performance gain on these parts at runtime.
> Built for asynchronism > ----------------------
> Today's web applications are integrating more concurrent realtime > data, so web frameworks need to support a full asynchronous HTTP > programming model. Play 1.x was initially designed to handle classic > Web applications with many short lived requests. But now, the event > model is the way to go for persistent connections - though comet, > long-polling and WebSockets.
> Play 1.2 already provides great asynchronous HTTP support and > WebScokets using continuations. Play 2.0 will be architected from the > start under the assumption that every request is potentially long > living. We want, for instance, to generalize Controller and > WebsocketController concepts into one single simple model that fits > all needs.
> But that’s not all: we also need a powerful way to schedule and run > long running tasks. Although the original Play 1.0 Jobs model was > introduced for this, we really need something more powerful and > robust. The Actor
Looks like you are continuing to push the envelope with Play. I know it must have been hard to make the call to make a drastic non-backward compatible change in Play 2.0, but I think it's the right move. I wonder how this will impact the 3rd party modules already available for Play 1.x. How different are things? Would a lot of the modules need to be upgraded?
For me, Play has really been a boon to productivity. I use it all the time and recommend it to everyone I come across. The biggest hurdle is definitely the view/templating layer - it is where I spend 70% of my time at when coding a Play application. There's still a lot of hand crafting and because of its nature, IDE support is pretty bad. I hope the new templating technology alleviates this problem.
I use Play every day in many sites, and I'm now really excited about
Play 2! I'm sure it will be great.
However, can I make one suggestion? Don't re-invent the wheel with
type-safe declarations in the Scala templates.
Instead, I think you should use the declarations used in a popular JS
templating library -- preferably Closure Templates/Library.
I do this right now in tags and views, and it makes converting to
Closure Templates much easier:
> Looks like you are continuing to push the envelope with Play. I know it must
> have been hard to make the call to make a drastic non-backward compatible
> change in Play 2.0, but I think it's the right move. I wonder how this will
> impact the 3rd party modules already available for Play 1.x. How different
> are things? Would a lot of the modules need to be upgraded?
> For me, Play has really been a boon to productivity. I use it all the time
> and recommend it to everyone I come across. The biggest hurdle is definitely
> the view/templating layer - it is where I spend 70% of my time at when
> coding a Play application. There's still a lot of hand crafting and because
> of its nature, IDE support is pretty bad. I hope the new templating
> technology alleviates this problem.
> -- > You received this message because you are subscribed to the Google Groups > "play-framework" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
I am going to disagree with some people here, and make a plea to go
the extra mile to make upgrades from old versions as painless as
possible.
You are obviously trying to move things forward, but don't annoy
existing users. We have been using play for live client projects since
version 1.0.1, we are currently running all live applications
(currently about 20) on 1.0.3.3. We have already struggled to upgrade
to 1.2.3 due to fairly large API changes, which in many cases could
have been minimised by keeping some backwards compatible methods while
still adding the new functionality. But the changes have been quite
ruthless and constantly having to revisit old code to upgrade play
versions is a pain many commercial developers could do without. Yes we
can leave applications on the old version, but by deprecating methods
and having them point to newer versions is much nicer for developers
than ruthlessly dumping them. We often want to utilise some of the
fixes & new features, but don't because of the pain to upgrade an
application to support a newer version.
We are not all playing at this (excuse the pun), we are trying to run
commercial development businesses, and don't want to be penalised for
being an early adopter by people taking theoretical high ground on
backwards compatibility. Backwards compatibility is price that
successful and stable projects have to live with. I appreciate this is
major version we are talking about here, but the more consideration
for this the better.
So having said that, and with all the talking of making things modular
and plug and play etc. Can things such as the database/storage plugin,
and template languages all be managed as modules. If you could do
this, it would make an upgrade easier, by selecting the JPA/hibernate
module and Groovy template modules as default (per application, not in
Play itself), then the upgrade path will be simpler. Then if you could
specify the database and template settings in an annotation per
controller, it would allow existing code to run, while gradually
converting and creating new functionality on the new modules.
I guess this was rather long and rambling, but essentially, please be
very careful with this. Many of us live in the real world, not fantasy
play land, we need to keep up with latest versions, so make the
upgrade path as simple as possible. I don't always think this happened
with Play. To continue its success, I think it is needed.
Also any ETA on this? It is on my schedule to put the leg work in to
upgrade to Play 1.2.3 over the next couple of months. Is it even worth
doing this? If there is going to be no more substantial development on
the Play 1 branch, I will stick with 1.0.3.2, and only consider the
move to Play 2.
On Wed, Sep 7, 2011 at 1:24 PM, Ivan Meredith <i...@ivan.net.nz> wrote: > Nice! Great to see scala 2.9 in the repo :D
> I see anorm hasn't bean ported yet... btw, I take it you meant ebean > for java, anorm still preferred for scala?
> On 7 September 2011 21:39, Guillaume Bort <guillaume.b...@gmail.com> wrote: >> Hi everyone,
>> Since 2007, we have been working on making Java web application >> development easier. Play started as an internal project at Zenexity >> and was heavily influenced by our way of doing Web projects: focusing >> on developer productivity, respecting Web architecture, and using from >> the start a fresh approach to packaging conventions - breaking where >> it made sense the so-called JEE best practices.
>> In 2009, we decided to share these ideas with the community as an open >> source project. The immediate feedback was extremely positive and the >> project gained a lot of traction. Today - after two years of active >> development - Play has several versions, an animated community of >> 3,000 people, with a growing number of applications running in >> production all over the globe.
>> Opening a project to the world certainly means more feedback, but it >> also means discovering and learning about new use cases, requiring >> features and un-earthing bugs that we were not specifically considered >> in the original design and assumptions. During the two years of work >> on Play as an open source project we have worked to fix all of these >> kind of issues, as well as to integrate new features to support a >> wider range of scenarios. As the project has grown, we have learned a >> lot from our community and from our own experience - using Play in >> more and more complex and varied projects.
>> In the meantime, technology and the Web have continued to evolve. The >> Web has become the central point of all applications. HTML, CSS and >> Javascript technologies have evolved quickly - making it almost >> impossible for a server side framework to follow. The whole Web >> architecture is fast moving towards real-time, and the emerging >> requirements of today's project profiles means SQL no longer works as >> the exclusive datastore technology. At the programming languages level >> we've witnessed some monumental changes with several JVM languages, >> including Scala, gaining popularity.
>> That's why we think it's now time to move on, and to consider the next >> major version of Play. Welcome Play 2.0!
>> Native support for Java and Scala >> ---------------------------------
>> In Play 1.1, we started exploring the possibility of using the Scala >> programming language for writing Play applications. We initially >> introduced this work as an external module to be able to experiment >> freely without impacting the framework itself.
>> Properly integrating Scala into a Java-based framework is not trivial. >> Considering Scala’s compatibility with Java, one can quickly achieve a >> first naive integration that simply uses Scala’s syntax instead of >> Java’s. This, however, is certainly not the optimal way of using the >> language. Scala is a mix of true object orientation with functional >> programming. Leveraging the full power of Scala requires rethinking >> most of the framework’s APIs. After several versions we now have a >> clean Scala module that allows the use of most of Play's features from >> Scala, in a Scala-ish manner.
>> Now, we are reaching the limits of what we can do with Scala support >> as a separate module. Initial design choices we made in Play 1.x, >> relying heavily on Java reflection API and byte code manipulation, >> have made it harder to progress without completely rethinking some >> essential parts of Play’s internals. Meanwhile, we have created >> several awesome components for the Scala module, like the new >> type-safe template engine and the brand new SQL access component >> Anorm. So we have decided that, to fully unleash the power of Scala >> with Play, we are moving Scala support from a separate module to the >> core of Play 2.0, which will be designed from the beginning to >> natively support Scala as a programming language.
>> Java, on the other hand, is certainly not getting any less support >> from Play 2.0; quite the contrary. The Play 2.0 build provides us with >> an opportunity to enhance the development experience for Java >> developers. Backed by our experience throughout the project we have a >> clear idea of what we need to achieve and what mistakes we have to >> avoid.
>> Powerful build system >> ---------------------
>> From the beginning we have chosen a fresh way to run, compile and >> deploy Play applications. At the time it may have looked like an >> esoteric design - but it was crucial to providing an asynchronous HTTP >> API instead of the standard Servlet API, short feedback cycles through >> live compilation and reloading of source code during development, and >> promoting a fresh packaging approach. Consequently, It was difficult >> to make Play follow the standard JEE conventions.
>> Today, this idea of container-less deployment is more and more >> accepted in the Java world. It's a design choice that has allowed the >> Play framework to run natively on platforms like Heroku, which >> introduced a model that we consider the future of Java applications >> deployment on elastic PaaS platforms.
>> Existing Java build systems, however, were not flexible enough to >> support this new approach. Since we wanted to provide straightforward >> tools to run and deploy Play applications, in Play 1.x we created a >> collection of Python scripts to handle all build and deployment >> related tasks.
>> But developers using Play for more enterprise-scale projects, which >> require build process customization and integration with their >> existing company build systems, were a bit lost. The Python scripts we >> provide with Play 1.x are in no way a fully featured build system and >> are not easily customizable. That's why we've decided to go for a more >> powerful build system for Play 2.0.
>> As we need a modern build tool, flexible enough to support Play >> original conventions and able to build Java and Scala projects, we >> have chosen to integrate SBT in Play 2.0. This, however, should not >> scare existing Play users who are happy with the simplicity of Play >> build. We are leveraging the same simple play new, run, start >> experience on top of an extensible model: Play 2.0 will come with a >> preconfigured build script that will just work for most users. On the >> other hand, if you need to change the way your application is built, >> deployed, etc., a Play project being a standard SBT project will hand >> you all the power to customize and adapt it to your special needs. >> This also mean better integration with Maven projects out of the box, >> the ability to package and publish your project as a simple set of jar >> files to any repository, and especially live compiling and reloading >> at development time of any depended project even for standard Java or >> Scala libraries projects.
>> Focused on type safety >> ----------------------
>> One benefit of using Java as programming language for writing Play >> applications is that the Java compiler can check certain parts of your >> code. This is not only useful for detecting mistakes early in the >> development process, but it also makes it a lot easier to work on >> large projects with a lot developers involved.
>> Adding Scala to the mix for Play 2.0, we will clearly benefit from >> even stronger compiler guarantees - but that’s not enough. In Play >> 1.x, the template system is dynamic, based on the Groovy language, and >> the compiler can’t do much for you. As a result, errors in templates >> can only be detected at runtime. The same goes for verification of >> glue code with controllers.
>> We really want to push further this idea of having Play check most of >> your code at compilation time in the 2.0 version. Accordingly, we have >> decided to use the Scala based template engine as the default for Play >> applications - even for developers using Java as the main programming >> language. This doesn't mean that you have to become a Scala expert to >> write templates in Play 2.0, just like you were not really required to >> know Groovy to write templates in Play 1.x. Scala will be mainly used >> to navigate your object graph in order to display relevant information >> with a syntax that is very close to the Java one. However if you want >> to unleash the power of Scala to write advanced templates >> abstractions, you will quickly discover how Scala, being expression >> oriented and functional, is a perfect fit for a template engine.
>> And that's not only true for the template engine: the routing system >> will also be fully type-checked. Play 2.0 will check all your routes' >> descriptions, and verify that the everything is coherent, including >> the reverse routing part.
>> As a nice side effect, being fully compiled, the templates and route >> files will be easier to package and reuse and you can expect high >> performance gain on these parts at runtime.
>> Built for asynchronism >> ----------------------
>> Today's web applications are integrating more concurrent realtime >> data, so web frameworks need to support a full asynchronous HTTP >> programming model. Play 1.x was initially designed to handle classic >> Web applications with many short lived requests. But now, the event >> model is the way to go for persistent connections - though comet, >> long-polling and WebSockets.
> However, can I make one suggestion? Don't re-invent the wheel with > type-safe declarations in the Scala templates.
We don't want to reinvent the wheel. The whole approach and syntax is borrowed from ASP.net Razor template engine. And signature declaration are just plain Scala declaration.
On Wed, Sep 7, 2011 at 1:47 PM, Michael Boyd <mic.t.b...@gmail.com> wrote: > I use Play every day in many sites, and I'm now really excited about > Play 2! I'm sure it will be great.
> However, can I make one suggestion? Don't re-invent the wheel with > type-safe declarations in the Scala templates. > Instead, I think you should use the declarations used in a popular JS > templating library -- preferably Closure Templates/Library. > I do this right now in tags and views, and it makes converting to > Closure Templates much easier:
> On Sep 7, 1:35 pm, Dave Cheong <d...@davecheong.com> wrote: >> Thanks for the update Guillaume.
>> Looks like you are continuing to push the envelope with Play. I know it must >> have been hard to make the call to make a drastic non-backward compatible >> change in Play 2.0, but I think it's the right move. I wonder how this will >> impact the 3rd party modules already available for Play 1.x. How different >> are things? Would a lot of the modules need to be upgraded?
>> For me, Play has really been a boon to productivity. I use it all the time >> and recommend it to everyone I come across. The biggest hurdle is definitely >> the view/templating layer - it is where I spend 70% of my time at when >> coding a Play application. There's still a lot of hand crafting and because >> of its nature, IDE support is pretty bad. I hope the new templating >> technology alleviates this problem.
>> dave
> -- > You received this message because you are subscribed to the Google Groups "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
It is very difficult for a major 2.0 release to promise backward compatibility without adding a lot of complexity to the project.
What's matter for us is to continue to support and maintain the previous versions that are already running so many applications. And we will do it. As you know, when we had the security alert lately, we fixed all versions, including the 1.0.3.x. And we will continue to do it, even after the 2.0 release. We have also a lot of applications running on Play 1.x and we will surely not rewrite them all, or abandon them.
If you have already several applications running on Play 1.0.3.3 for your customers, it's fine, there is no need to migrate them. Just consider 2.0 for you next project, or if it's worse it for a particular application.
On the other hand, I'm sure than once the 2.0 version will be ready, the community will help to port the current Groovy template engine or JPA based Model API as Play 2.0 modules to ease migration of old projects. It should be fairly easy, just for now we want to focus on developing the core of the next major version.
On Wed, Sep 7, 2011 at 2:21 PM, Daryl <dark...@hotmail.com> wrote: > Hi
> I am going to disagree with some people here, and make a plea to go > the extra mile to make upgrades from old versions as painless as > possible.
> You are obviously trying to move things forward, but don't annoy > existing users. We have been using play for live client projects since > version 1.0.1, we are currently running all live applications > (currently about 20) on 1.0.3.3. We have already struggled to upgrade > to 1.2.3 due to fairly large API changes, which in many cases could > have been minimised by keeping some backwards compatible methods while > still adding the new functionality. But the changes have been quite > ruthless and constantly having to revisit old code to upgrade play > versions is a pain many commercial developers could do without. Yes we > can leave applications on the old version, but by deprecating methods > and having them point to newer versions is much nicer for developers > than ruthlessly dumping them. We often want to utilise some of the > fixes & new features, but don't because of the pain to upgrade an > application to support a newer version.
> We are not all playing at this (excuse the pun), we are trying to run > commercial development businesses, and don't want to be penalised for > being an early adopter by people taking theoretical high ground on > backwards compatibility. Backwards compatibility is price that > successful and stable projects have to live with. I appreciate this is > major version we are talking about here, but the more consideration > for this the better.
> So having said that, and with all the talking of making things modular > and plug and play etc. Can things such as the database/storage plugin, > and template languages all be managed as modules. If you could do > this, it would make an upgrade easier, by selecting the JPA/hibernate > module and Groovy template modules as default (per application, not in > Play itself), then the upgrade path will be simpler. Then if you could > specify the database and template settings in an annotation per > controller, it would allow existing code to run, while gradually > converting and creating new functionality on the new modules.
> I guess this was rather long and rambling, but essentially, please be > very careful with this. Many of us live in the real world, not fantasy > play land, we need to keep up with latest versions, so make the > upgrade path as simple as possible. I don't always think this happened > with Play. To continue its success, I think it is needed.
> Also any ETA on this? It is on my schedule to put the leg work in to > upgrade to Play 1.2.3 over the next couple of months. Is it even worth > doing this? If there is going to be no more substantial development on > the Play 1 branch, I will stick with 1.0.3.2, and only consider the > move to Play 2.
> thanks
> Daryl.
> -- > You received this message because you are subscribed to the Google Groups "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
I think the point I was hoping to make, is that the work on making
storage/template functionality pluggable is the key here, then having
modules for Play 1 compatibility is the obvious stepping stone for
upgrades. I would expect the compatibility modules to come later,
ensuring this support and ease of use/configuration is my biggest
concern.
The added bonus of being able to configure this on a controller basis
would also help, allowing the changes to be made over time, while
still supporting the newer options. Is selection of storage/templates
using an annotation per controller an option? If this could be built
in at this early stage, then it gives much more flexibility for
applications to be gradually upgraded? I have seen previous requests/
questions on here, that would have been possible by selecting module/
plugin options per controller, so I think any consideration for this
would be appreciated.
thanks
Daryl.
On Sep 7, 1:54 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> It is very difficult for a major 2.0 release to promise backward
> compatibility without adding a lot of complexity to the project.
> What's matter for us is to continue to support and maintain the
> previous versions that are already running so many applications. And
> we will do it. As you know, when we had the security alert lately, we
> fixed all versions, including the 1.0.3.x. And we will continue to do
> it, even after the 2.0 release. We have also a lot of applications
> running on Play 1.x and we will surely not rewrite them all, or
> abandon them.
> If you have already several applications running on Play 1.0.3.3 for
> your customers, it's fine, there is no need to migrate them. Just
> consider 2.0 for you next project, or if it's worse it for a
> particular application.
> On the other hand, I'm sure than once the 2.0 version will be ready,
> the community will help to port the current Groovy template engine or
> JPA based Model API as Play 2.0 modules to ease migration of old
> projects. It should be fairly easy, just for now we want to focus on
> developing the core of the next major version.
> On Wed, Sep 7, 2011 at 2:21 PM, Daryl <dark...@hotmail.com> wrote:
> > Hi
> > I am going to disagree with some people here, and make a plea to go
> > the extra mile to make upgrades from old versions as painless as
> > possible.
> > You are obviously trying to move things forward, but don't annoy
> > existing users. We have been using play for live client projects since
> > version 1.0.1, we are currently running all live applications
> > (currently about 20) on 1.0.3.3. We have already struggled to upgrade
> > to 1.2.3 due to fairly large API changes, which in many cases could
> > have been minimised by keeping some backwards compatible methods while
> > still adding the new functionality. But the changes have been quite
> > ruthless and constantly having to revisit old code to upgrade play
> > versions is a pain many commercial developers could do without. Yes we
> > can leave applications on the old version, but by deprecating methods
> > and having them point to newer versions is much nicer for developers
> > than ruthlessly dumping them. We often want to utilise some of the
> > fixes & new features, but don't because of the pain to upgrade an
> > application to support a newer version.
> > We are not all playing at this (excuse the pun), we are trying to run
> > commercial development businesses, and don't want to be penalised for
> > being an early adopter by people taking theoretical high ground on
> > backwards compatibility. Backwards compatibility is price that
> > successful and stable projects have to live with. I appreciate this is
> > major version we are talking about here, but the more consideration
> > for this the better.
> > So having said that, and with all the talking of making things modular
> > and plug and play etc. Can things such as the database/storage plugin,
> > and template languages all be managed as modules. If you could do
> > this, it would make an upgrade easier, by selecting the JPA/hibernate
> > module and Groovy template modules as default (per application, not in
> > Play itself), then the upgrade path will be simpler. Then if you could
> > specify the database and template settings in an annotation per
> > controller, it would allow existing code to run, while gradually
> > converting and creating new functionality on the new modules.
> > I guess this was rather long and rambling, but essentially, please be
> > very careful with this. Many of us live in the real world, not fantasy
> > play land, we need to keep up with latest versions, so make the
> > upgrade path as simple as possible. I don't always think this happened
> > with Play. To continue its success, I think it is needed.
> > Also any ETA on this? It is on my schedule to put the leg work in to
> > upgrade to Play 1.2.3 over the next couple of months. Is it even worth
> > doing this? If there is going to be no more substantial development on
> > the Play 1 branch, I will stick with 1.0.3.2, and only consider the
> > move to Play 2.
> > thanks
> > Daryl.
> > --
> > You received this message because you are subscribed to the Google Groups "play-framework" group.
> > To post to this group, send email to play-framework@googlegroups.com.
> > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/play-framework?hl=en.
Sounds very exciting! Don't let either of the following detract from
the main point that this sounds cool, and it's fantastic to see Play
moving forward, unlike so many projects that get a couple of years in
and just...stop. Clearly not the case here!
I'm sorry to hear you're rewriting a lot of the core in Scala because
it's not a language I know and I have an irrational bias toward
languages that are syntactically derived from B (so C, C++, Java,
JavaScript, C#, etc.). I realize I don't have to know Scala to create
Play apps, but I liked the idea of being able to get my hands dirty on
the internals as necessary (and hopefully contribute back). But I
guess either I'll have to not do that, or I'll have to bite the bullet
and learn a new language. (I've been doing this for well over 20
years, it won't be that much of a problem.)
Since you're going to be doing a lot of work in the source, could I
put in a request for *ALL* public API methods and fields to be fully
Javadoc'd? With more than one-liners (or one-liners linking to the
appropriate further documentation), ideally, but in many cases the
current API docs have no descriptions in the Javadoc at all, or such
minimal ones that they may as well not be there (the annotations in
particular suffer here).
I'm not complaining. Play is clearly a great framework and there is a
fair bit of documentation, but if you're going to be kicking around in
the source *anyway*, improving the Javadoc as you go could be a big
win.
Cheers -- and best of luck with Play 2!
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
> The added bonus of being able to configure this on a controller basis > would also help, allowing the changes to be made over time, while > still supporting the newer options. Is selection of storage/templates > using an annotation per controller an option? If this could be built > in at this early stage, then it gives much more flexibility for > applications to be gradually upgraded? I have seen previous requests/ > questions on here, that would have been possible by selecting module/ > plugin options per controller, so I think any consideration for this > would be appreciated.
No need annotation for that. It will clearly be different API, so if you use a statically compiled template it will just be a standard method call, but if you want to evaluate a Groovy template (if a port if available in 2.0) you will just have to call render()
On Wed, Sep 7, 2011 at 3:31 PM, Daryl <dark...@hotmail.com> wrote: > Thanks Guillaume.
> I think the point I was hoping to make, is that the work on making > storage/template functionality pluggable is the key here, then having > modules for Play 1 compatibility is the obvious stepping stone for > upgrades. I would expect the compatibility modules to come later, > ensuring this support and ease of use/configuration is my biggest > concern.
> The added bonus of being able to configure this on a controller basis > would also help, allowing the changes to be made over time, while > still supporting the newer options. Is selection of storage/templates > using an annotation per controller an option? If this could be built > in at this early stage, then it gives much more flexibility for > applications to be gradually upgraded? I have seen previous requests/ > questions on here, that would have been possible by selecting module/ > plugin options per controller, so I think any consideration for this > would be appreciated.
> thanks
> Daryl.
> On Sep 7, 1:54 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote: >> It is very difficult for a major 2.0 release to promise backward >> compatibility without adding a lot of complexity to the project.
>> What's matter for us is to continue to support and maintain the >> previous versions that are already running so many applications. And >> we will do it. As you know, when we had the security alert lately, we >> fixed all versions, including the 1.0.3.x. And we will continue to do >> it, even after the 2.0 release. We have also a lot of applications >> running on Play 1.x and we will surely not rewrite them all, or >> abandon them.
>> If you have already several applications running on Play 1.0.3.3 for >> your customers, it's fine, there is no need to migrate them. Just >> consider 2.0 for you next project, or if it's worse it for a >> particular application.
>> On the other hand, I'm sure than once the 2.0 version will be ready, >> the community will help to port the current Groovy template engine or >> JPA based Model API as Play 2.0 modules to ease migration of old >> projects. It should be fairly easy, just for now we want to focus on >> developing the core of the next major version.
>> On Wed, Sep 7, 2011 at 2:21 PM, Daryl <dark...@hotmail.com> wrote: >> > Hi
>> > I am going to disagree with some people here, and make a plea to go >> > the extra mile to make upgrades from old versions as painless as >> > possible.
>> > You are obviously trying to move things forward, but don't annoy >> > existing users. We have been using play for live client projects since >> > version 1.0.1, we are currently running all live applications >> > (currently about 20) on 1.0.3.3. We have already struggled to upgrade >> > to 1.2.3 due to fairly large API changes, which in many cases could >> > have been minimised by keeping some backwards compatible methods while >> > still adding the new functionality. But the changes have been quite >> > ruthless and constantly having to revisit old code to upgrade play >> > versions is a pain many commercial developers could do without. Yes we >> > can leave applications on the old version, but by deprecating methods >> > and having them point to newer versions is much nicer for developers >> > than ruthlessly dumping them. We often want to utilise some of the >> > fixes & new features, but don't because of the pain to upgrade an >> > application to support a newer version.
>> > We are not all playing at this (excuse the pun), we are trying to run >> > commercial development businesses, and don't want to be penalised for >> > being an early adopter by people taking theoretical high ground on >> > backwards compatibility. Backwards compatibility is price that >> > successful and stable projects have to live with. I appreciate this is >> > major version we are talking about here, but the more consideration >> > for this the better.
>> > So having said that, and with all the talking of making things modular >> > and plug and play etc. Can things such as the database/storage plugin, >> > and template languages all be managed as modules. If you could do >> > this, it would make an upgrade easier, by selecting the JPA/hibernate >> > module and Groovy template modules as default (per application, not in >> > Play itself), then the upgrade path will be simpler. Then if you could >> > specify the database and template settings in an annotation per >> > controller, it would allow existing code to run, while gradually >> > converting and creating new functionality on the new modules.
>> > I guess this was rather long and rambling, but essentially, please be >> > very careful with this. Many of us live in the real world, not fantasy >> > play land, we need to keep up with latest versions, so make the >> > upgrade path as simple as possible. I don't always think this happened >> > with Play. To continue its success, I think it is needed.
>> > Also any ETA on this? It is on my schedule to put the leg work in to >> > upgrade to Play 1.2.3 over the next couple of months. Is it even worth >> > doing this? If there is going to be no more substantial development on >> > the Play 1 branch, I will stick with 1.0.3.2, and only consider the >> > move to Play 2.
>> > thanks
>> > Daryl.
>> > -- >> > You received this message because you are subscribed to the Google Groups "play-framework" group. >> > To post to this group, send email to play-framework@googlegroups.com. >> > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. >> > For more options, visit this group athttp://groups.google.com/group/play-framework?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
It is great that Play is moving on and not becoming stale.
I've just been looking through the kiki sample code; not downloaded it
yet as I'm currently at work. In the views, the controllers package
is being imported using the line
@import controllers._
Couldn't the controllers always be imported by default; so that this
piece of boilerplate isn't needed at the beginning of every view.
> Since 2007, we have been working on making Java web application
> development easier. Play started as an internal project at Zenexity
> and was heavily influenced by our way of doing Web projects: focusing
> on developer productivity, respecting Web architecture, and using from
> the start a fresh approach to packaging conventions - breaking where
> it made sense the so-called JEE best practices.
> In 2009, we decided to share these ideas with the community as an open
> source project. The immediate feedback was extremely positive and the
> project gained a lot of traction. Today - after two years of active
> development - Play has several versions, an animated community of
> 3,000 people, with a growing number of applications running in
> production all over the globe.
> Opening a project to the world certainly means more feedback, but it
> also means discovering and learning about new use cases, requiring
> features and un-earthing bugs that we were not specifically considered
> in the original design and assumptions. During the two years of work
> on Play as an open source project we have worked to fix all of these
> kind of issues, as well as to integrate new features to support a
> wider range of scenarios. As the project has grown, we have learned a
> lot from our community and from our own experience - using Play in
> more and more complex and varied projects.
> In the meantime, technology and the Web have continued to evolve. The
> Web has become the central point of all applications. HTML, CSS and
> Javascript technologies have evolved quickly - making it almost
> impossible for a server side framework to follow. The whole Web
> architecture is fast moving towards real-time, and the emerging
> requirements of today's project profiles means SQL no longer works as
> the exclusive datastore technology. At the programming languages level
> we've witnessed some monumental changes with several JVM languages,
> including Scala, gaining popularity.
> That's why we think it's now time to move on, and to consider the next
> major version of Play. Welcome Play 2.0!
> Native support for Java and Scala
> ---------------------------------
> In Play 1.1, we started exploring the possibility of using the Scala
> programming language for writing Play applications. We initially
> introduced this work as an external module to be able to experiment
> freely without impacting the framework itself.
> Properly integrating Scala into a Java-based framework is not trivial.
> Considering Scala’s compatibility with Java, one can quickly achieve a
> first naive integration that simply uses Scala’s syntax instead of
> Java’s. This, however, is certainly not the optimal way of using the
> language. Scala is a mix of true object orientation with functional
> programming. Leveraging the full power of Scala requires rethinking
> most of the framework’s APIs. After several versions we now have a
> clean Scala module that allows the use of most of Play's features from
> Scala, in a Scala-ish manner.
> Now, we are reaching the limits of what we can do with Scala support
> as a separate module. Initial design choices we made in Play 1.x,
> relying heavily on Java reflection API and byte code manipulation,
> have made it harder to progress without completely rethinking some
> essential parts of Play’s internals. Meanwhile, we have created
> several awesome components for the Scala module, like the new
> type-safe template engine and the brand new SQL access component
> Anorm. So we have decided that, to fully unleash the power of Scala
> with Play, we are moving Scala support from a separate module to the
> core of Play 2.0, which will be designed from the beginning to
> natively support Scala as a programming language.
> Java, on the other hand, is certainly not getting any less support
> from Play 2.0; quite the contrary. The Play 2.0 build provides us with
> an opportunity to enhance the development experience for Java
> developers. Backed by our experience throughout the project we have a
> clear idea of what we need to achieve and what mistakes we have to
> avoid.
> Powerful build system
> ---------------------
> From the beginning we have chosen a fresh way to run, compile and
> deploy Play applications. At the time it may have looked like an
> esoteric design - but it was crucial to providing an asynchronous HTTP
> API instead of the standard Servlet API, short feedback cycles through
> live compilation and reloading of source code during development, and
> promoting a fresh packaging approach. Consequently, It was difficult
> to make Play follow the standard JEE conventions.
> Today, this idea of container-less deployment is more and more
> accepted in the Java world. It's a design choice that has allowed the
> Play framework to run natively on platforms like Heroku, which
> introduced a model that we consider the future of Java applications
> deployment on elastic PaaS platforms.
> Existing Java build systems, however, were not flexible enough to
> support this new approach. Since we wanted to provide straightforward
> tools to run and deploy Play applications, in Play 1.x we created a
> collection of Python scripts to handle all build and deployment
> related tasks.
> But developers using Play for more enterprise-scale projects, which
> require build process customization and integration with their
> existing company build systems, were a bit lost. The Python scripts we
> provide with Play 1.x are in no way a fully featured build system and
> are not easily customizable. That's why we've decided to go for a more
> powerful build system for Play 2.0.
> As we need a modern build tool, flexible enough to support Play
> original conventions and able to build Java and Scala projects, we
> have chosen to integrate SBT in Play 2.0. This, however, should not
> scare existing Play users who are happy with the simplicity of Play
> build. We are leveraging the same simple play new, run, start
> experience on top of an extensible model: Play 2.0 will come with a
> preconfigured build script that will just work for most users. On the
> other hand, if you need to change the way your application is built,
> deployed, etc., a Play project being a standard SBT project will hand
> you all the power to customize and adapt it to your special needs.
> This also mean better integration with Maven projects out of the box,
> the ability to package and publish your project as a simple set of jar
> files to any repository, and especially live compiling and reloading
> at development time of any depended project even for standard Java or
> Scala libraries projects.
> Focused on type safety
> ----------------------
> One benefit of using Java as programming language for writing Play
> applications is that the Java compiler can check certain parts of your
> code. This is not only useful for detecting mistakes early in the
> development process, but it also makes it a lot easier to work on
> large projects with a lot developers involved.
> Adding Scala to the mix for Play 2.0, we will clearly benefit from
> even stronger compiler guarantees - but that’s not enough. In Play
> 1.x, the template system is dynamic, based on the Groovy language, and
> the compiler can’t do much for you. As a result, errors in templates
> can only be detected at runtime. The same goes for verification of
> glue code with controllers.
> We really want to push further this idea of having Play check most of
> your code at compilation time in the 2.0 version. Accordingly, we have
> decided to use the Scala based template engine as the default for Play
> applications - even for developers using Java as the main programming
> language. This doesn't mean that you have to become a Scala expert to
> write templates in Play 2.0, just like you were not really required to
> know Groovy to write templates in Play 1.x. Scala will be mainly used
> to navigate your object graph in order to display relevant information
> with a syntax that is very close to the Java one. However if you want
> to unleash the power of Scala to write advanced templates
> abstractions, you will quickly discover how Scala, being expression
> oriented and functional, is a perfect fit for a template engine.
> And that's not only true for the template engine: the routing system
> will also be fully type-checked. Play 2.0 will check all your routes'
> descriptions, and verify that the everything is coherent, including
> the reverse routing part.
> As a nice side effect, being fully compiled, the templates and route
> files will be easier to package and reuse and you can expect high
> performance gain on these parts at runtime.
> Built for asynchronism
> ----------------------
> Today's web applications are integrating more concurrent realtime
> data, so web frameworks need to support a full asynchronous HTTP
> programming model. Play 1.x was initially designed to handle classic
> Web applications with many short lived requests. But now, the event
> model is the way to go for persistent connections - though comet,
> long-polling and WebSockets.
> Play 1.2 already provides great asynchronous HTTP support
