How to make Play 2.0 better and help supporting Play 1.2.x

[Guillaume Bort]

Hi everyone,

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

[green]

Hi Guillaume and core team,

Looks all good and thank you! 

Just want to clarify is 1.x entered maintenance model or just 1.2.x? In other words can we expect version 1.3 and more with functional improvements?

Kind Regards,

Green

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

[Guillaume Bort]

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.

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

[ikeike443]

Great.

I am ready to help you all on 1.x project in development, documentation and promoting.

Of course, I will support 2.0 too.

Regards

ikeike443

2012年4月3日火曜日19時42分13秒 UTC+9 Guillaume Bort:

[Pascal Voitot Dev]

Thanks Guillaume for this clarification!!!!
Exactly what I expected after this short period of anarchy in the google group (almost looked like a french election debate ;))

Long life to Play ;)

--

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.

[Andy]

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

Thanks Guillaume.

While integrating giter8 into Play is a good idea, I think it's better
to have an "official" Play Java release with router and template
engine already integrated. That way people, especially those
unfamiliar with Play, wouldn't have to try to figure out which routers
and template engines work or not work with Play. And it'd be easier to
get help and bug fixes if most people are using the same router and
template engine.

Japid has a port for Play 2. Is there any Java router available for
Play 2?

[Andy Czerwonka]

+1

[GrailsDeveloper]

+1

[Guillaume Bort]

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

[Andy]

I think the key isn't necessarily to find the "best" Java template
engine and router per se.

The key is to offer a default choice so that people won't need to hunt
down and evaluate multiple routers and template engines before
starting to use Play 2.

Play 2 already offers a default choice for Scala router and Scala
template engine. Those 2 aren't necessary the "best" out of all Scala
routers and all Scala template engines available. But they are the
default choices and that's good enough for most people.

What I'm saying is Play should do for Java what it already is doing
for Scala: offer a default choice. It would go a long way towards
improving the user-friendliness of Play for Java programmers.

[Marcos Pereira]

-1.

IMHO, having a standard way to use routes is better for a lot of reasons: better (and consistent) documentation, more people using means more messages/information about problems and troubleshooting, less code to maintain and evolve, etc. Routes is a very simple component. It is almost as simple as a java properties file. Moreover, the report on browser is clear enough to track ans solve problems.

What are the advantages of having a specific Java router implementation?

Guillaume, 

Thank you very much for your time to clarify the discussions about the project future. Just one single question: how can we contribute more to play 2.0? Where do you guys need help?

Kind Regards,

--
http://about.me/marcospereira

[Drew Hamlett]

I think having Java templates and Java routing within a Java project just helps with cohesion.  Just as Scala templates with Scala routing do with a Scala project.  I thought this made sense in Play 1.x, which is why we use Japid at my company.  There is nothing wrong with the Groovy templates in my book, it just makes sense having a complete end to end java solution.  Minus the client of course where you have to use javascript.  In fact this actually first attracted me to Play.  It's a breath of fresh air to be able to use Java/Scala as a templating language as opposed to something like JSP/JSF markup.  

--
http://about.me/marcospereira

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.

[smallufo]

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>

[Yann Simon]

The fact that the router and the template engine is in Scala is only
an implementation detail.
As developer, you even do not have to know about that. You could learn
to use the template engine without to know that it is provided by
scala.

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.

[Daniel Dietrich]

+1 @Yann

[Pascal Voitot Dev]

see below

Pascal

On Tue, Apr 3, 2012 at 10:32 PM, Guillaume Bort <guillau...@gmail.com> wrote:

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

I agree and I want to add that I consider play2 as a still young framework, yet production ready to say it one more time. So, current design provides a very good ground with some features released in their purest expression without anything superfluous. From this early state, we can build everything we need as helpers, tools, templates etc...
Play2 is like plasticine: you get the material to do everything you want with some insurance that the ground on which you rely is robust and efficient.
 

But as I explained before I understand that some people will still
prefer a pure Java flavor.

As you, I can understand this but I find the purity argument around one given language a bit creepy also... but it's a very personal mind ;)
 

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.

+1 for this idea!

 

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

I really consider that it's worth doing the effort of diving into Scala Templates. You don't need to be a Scala developer or functional expert. You really get a more precise and robust template engine than any I've been using in Java world till now. I find Scala templates offer me a real way to "develop" my views as any other code I write as a developer. Exactly what I was looking to replace XML/tags stuff. Scala templates certainly require a few enhancements but it's already very good as it is. 

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.

+1
 

[Pascal Voitot Dev]

+2 @Yann

On Wed, Apr 4, 2012 at 10:12 AM, Daniel Dietrich <cafe...@googlemail.com> wrote:

+1 @Yann

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

[Ivan Meredith]

I imagine the default setup (ie option no1) is always going to be the
one that Typesafe/Zenexity officially support. Which is scala
templates and routes. That setup isn't a "scala" or "java" setup
though, rather its the "play2 official" setup which they (and others
including me) believe is good for both Java and Scala projects.

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.

[Nicolas Leroux]

On Apr 4, 2012, at 5:10 AM, smallufo wrote:

Does it mean there will never be 1.3 released ?

How about some commitment in 1.3 ? (such as multidb ?)

We will try to have multi db as a module (as it was before). The 1.3 is currently not API compatible with the 1.2 which might be a problem.

Nicolas

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.

[Engin Tekin]

I agree with Yann, It would be better option if we can speed up the current template engine.



04 Nisan 2012 Çarşamba 09:37:59 UTC+3 tarihinde yann yazdı:

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

> play-framework+unsubscribe@googlegroups.com.

[Guillaume Bort]

> Thank you very much for your time to clarify the discussions about the
> project future. Just one single question: how can we contribute more to play
> 2.0? Where do you guys need help?

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

[MSeifeddo]

I am glad that you are taking in the critism and doing something creative about it, rather than dismiss peoples opinions. 

What I was glad for was the fact that Play 1 was pure Java ( almost ) yet it allowed rapid development with excellent class reloader.

I can never convince anyone in an enterprise environment to move to something that is scala when we have over 2000 java developers and like 5 scala develpers.

Education is expensive. 

The move you just did, will only benefit small companies, with 10+ devs, that have some requirement of Java from the client, they would not look to towards Play but rather Grails or some other framework would have been their choice. 

I hope you continue to have an open mind and take in what others ( even if less talented ) have for an opinion, there is usally some substance. There have been many times that I have asked questions in other forums, that is not supported, but when googling it, I could find lots of people looking to do the same thing.

Good luck, I will keep watching the progress but for now I will have to keep waiting.