As promised, after the last week storm about Play 2.0 and the Play 1.x
future, I have involved the whole team to clarify the situation.
I\ The future of Play 1.2.x
Play 1.2.x is now is maintenance mode. We want to continue to support
it and to publish bug-fix releases with non-functional improvements
(performance,
security, stability, etc). The next release (1.2.5) will be released
by the end of the month.
There is really a lot of bug-reports and pull-requests on this branch,
and we know that we are late handling them properly. To improve the
situation, we clearly need more man power to help us on this task.
Thus we would like to welcome a few more committers from the
community. If you are interested helping us on this please let us know
(we would like to have experienced committers who already proven
themselves with several pull-requests or modules on the project, or
another open source project) - Nicolas Leroux will manage the
recruitment.
About functional improvements (new features, back-porting ideas from
2.0), we believe that Play 1.2.4 is already feature complete, and that
it wouldn't be beneficial to anyone to continue to add more features
on the existing code base. However if you really want something
supported for Play 1.2.x, you can still do it by providing a module.
We know that the current "modules" part on the website is not good
enough to support the current activity. It needs to be more open, and
to allow more community communication. That's why we will launch a new
project to provided a dedicated "community modules" website with all
these new required features.
Again, for this project, we would like to involve the community. If
you are interested to develop this application let us know - Peter
Hilton will manage this project.
We hope that these actions will help reassure people on the future of
Play 1.2.x, even if it stay in maintenance mode.
II\ The Play 2.x, Play 1.x relation.
We decided that it isn't a good idea to split the community with 2
Play projects (either Play classic vs. Play, or Play Java vs. Play
Scala).
We want it clear:
Play 1.x is the first generation of the Play project. It is stable and
mature. It is now in maintenance mode but fully supported with
professional services and by the community with non-functional
improvements.
It can be used in production, and is still a valid choice for projects
that don't need the new Play 2.0 (Scala, Async, etc.) features. It has
an extensive knowledge base, books, and an active modules community
(let's make that better with the new modules manager).
Play 2.x is the future. It is less mature currently (yet fully usable
for production project), with a less active community. We are all
working on it, to make it faster in development mode, and more
polished. It tooks 3 years after the 1.0 release for Play 1.2.4 to
reach this state. We need more time on Play 2.0 as well.
We will update the website to make it clearer for newcomers.
Explaining the current situation with a better separation between Play
1.2.x (documentation, download) and Play 2.x,
III\ Scala, Play 2.x pure Java
From the beginning of the Play 2.0 project, we wanted to create a Web
framework for the JVM allowing different APIs in different languages.
Currently we support both a Scala and a Java API, fully native and
idiomatic.
This is not true that you are required to write Scala to create a Play
2.0 Java application.
Still, I agree that the default flavor of Play 2.0 Java project comes
with a Scala based type safe (reverse)router, and the Scala template
engine. Even if we think that these components are very good and
beneficial for a Java developer, we can understand that some people
would prefer a 100% Java solution (With a Java based router, and a
Java based template engine).
Actually doing this is fully possible since in Play 2.x, every
components are pluggable. So, yes it possible to have pure Java flavor
of a Play 2.0 application without forking anything.
Still it needs to select the appropriate set of modules, and to
configure them properly. We know that is not an easy task for new
developers. That's why the next Play 2.x release will integrate with
'giter8' https://github.com/n8han/giter8, allowing everyone to create
and share it's Play 2.x project template with the community.
This way, I hope that we will see some pure Java flavor of Play 2.x
instead of seeing some people trying to fork Play 1.x (which require
really a lot of work, and wouldn't be beneficial to anyone).
Thank you for reading this, and I hope that it responds to everyone questions.
--
Guillaume Bort
--
Guillaume Bort
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
We understand that current Play 1.2.4 users need non-functional
improvement to fix stability,security and performance issues on their
existing applications. We don't think that functional changes are a
good think. We want all changes on 1.2.x fully backward compatibles.
Propositions like switch the default template engine, etc. can make
sense for some users, but surely not for the whole community. So all
these changes must be provided as modules.
We want users currently running on Play 1.2.4 reassured about the fact
they don't have to do a technical migration to Play 2.0, while
focusing innovation on the Play 2.0 branch (even for those not
interested by Scala like I just explained before).
--
Guillaume Bort
--
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/-/hyu5LMaeuJwJ.
If you have a pure Java template engine it will not be possible to use
it from Scala. The same apply for a Java only Router. Meaning that if
at some point you need to use Scala somewhere (because of a specific
need), you can't since you are locked to Java only.
So I still think that the current design provide a very good set of
components, with excellent flexibility, and it is the one we would
like promote (once fixed the compilation speed issues, I'm sure that
everyone will love it).
But as I explained before I understand that some people will still
prefer a pure Java flavor.
What does standard mean? We can imagine that 'play new' (without
specifying any project template) would propose the top community rated
project templates. This way if someone provide a very good set of
"Java only" components for Play 2.0 with the associated project
template, and the community love it, it will become a "de facto"
standard for Play 2.0.
Regarding the Java template engine available, there is already the
Japid one, 2 versions of the Play 1.x groovy one, and all the well
known template engine from the Java ecosystem (freemarker, velocity).
For a Java only router, it is perhaps possible to do a clone the the
current one in Java (the current Play 2.0 router support type-safety,
reverse route generation, automatic binding/unbinding, javascript), or
to do something different (based on annotations or JAX-RS for
example).
So for a Play 2.0 Java project without any Scala code, I can already
see multiple combinations. Which one is the best? I don't know yet.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
--
Guillaume Bort
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.
Once the compilation speed issues fixed, I do not see any point to
complaint about these as default choices anymore.
I personally find the router and the template engine awesome,
providing type safety that is very important, especially for big
projects.
I would prefer to fix the issues with the current router and template
engine instead of providing alternatives, just because the last ones
are written in java.
The more alternatives we have, the more bugs we have, and the more
fragmented the community is.
Can you imagine?
Someone asks a question, and first of all, we ask him:
- java / scala
- which router, which version
- which template, which version
....
Do not misunderstand me, I link the freedom to choose, and I think the
architecture of Play is very good for it. We already have a lot of
alternative template engines and even an alternative routing engine
(in scala)
But we need good default setup, and the current one is a good one on my opinion.
Yann
2012/4/4 Drew Hamlett <drew...@gmail.com>:
>>> To post to this group, send email to play-fr...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> play-framewor...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/play-framework?hl=en.
>>>
>>
> --
> 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/-/LZjPUhPvLmoJ.
>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
One of the goal of the current Play 2.0 component set, is that it
allows to mix both Java and Scala in the same project without up-front
decision. The router is able to call both Java and Scala controllers.
The template engine is usable natively from both Java and Scala.
If you have a pure Java template engine it will not be possible to use
it from Scala. The same apply for a Java only Router. Meaning that if
at some point you need to use Scala somewhere (because of a specific
need), you can't since you are locked to Java only.
So I still think that the current design provide a very good set of
components, with excellent flexibility, and it is the one we would
like promote (once fixed the compilation speed issues, I'm sure that
everyone will love it).
But as I explained before I understand that some people will still
prefer a pure Java flavor.
What does standard mean? We can imagine that 'play new' (without
specifying any project template) would propose the top community rated
project templates. This way if someone provide a very good set of
"Java only" components for Play 2.0 with the associated project
template, and the community love it, it will become a "de facto"
standard for Play 2.0.
Regarding the Java template engine available, there is already the
Japid one, 2 versions of the Play 1.x groovy one, and all the well
known template engine from the Java ecosystem (freemarker, velocity).
For a Java only router, it is perhaps possible to do a clone the the
current one in Java (the current Play 2.0 router support type-safety,
reverse route generation, automatic binding/unbinding, javascript), or
to do something different (based on annotations or JAX-RS for
example).
So for a Play 2.0 Java project without any Scala code, I can already
see multiple combinations. Which one is the best? I don't know yet.
--
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/-/RK1LJYKZkkEJ.
I really like the idea of play new giving a list of several options
though. And since its based on giter8, I imagine you could customize
one for private organizational use easily.
Does it mean there will never be 1.3 released ?How about some commitment in 1.3 ? (such as multidb ?)
2012/4/3 Guillaume Bort <guillau...@gmail.com>
1.x is entered in maintenance mode.
We understand that current Play 1.2.4 users need non-functional
improvement to fix stability,security and performance issues on their
existing applications. We don't think that functional changes are a
good think. We want all changes on 1.2.x fully backward compatibles.
>>> To post to this group, send email to play-framework@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> For more options, visit this group at
>>> http://groups.google.com/group/play-framework?hl=en.
>>>
>>
> --
> 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/-/LZjPUhPvLmoJ.
>
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
Yes we always need help.
The better way is to browse issues we already marked as 'confirmed'
and to provide a pull request for that.
However in order to really help us please take of your pull request:
- Have clean, and well formatted, documented (I mean at the API level
if you introduce something) code
- Solve the problem for both Java and Scala API (with idiomatic code
in both Scala and Java code. If you are new to scala, make a try, ask
for feedback, and be ready to fix if we propose something to change.)
- Have a clean (single commit if possible) git history to merge.
Don't try to push a pull request for something new (even if you think
it will be useful), without reporting the issue and have someone from
the team marked it as 'confirmed'. (Well sometimes it will work, but
sometimes we will not agree with that, and it will starts endless
discusions).
--
Guillaume Bort