1. It’s open source
2. It’s written in Play 2
Just to piss off the nay-sayers
3. Module creation
At the moment, to get a module into the module repository you have to get authorisation from a member of the Play team. I want to have a repo where you can upload any module, as long as it conforms to certain minimum requirements. These are
- a README file
- a license (preferably, but not constrained to, a business-friendly one)
- actual code, to prevent a bunch of empty modules being created
4. Open accounts
Users can create accounts by logging in via twitter, facebook, etc, and link multiple sign-in methods to their accounts.
Authentication will come via SecureSocial (so Jorge Aliss needs to start coding!) and authorisation will be implemented in Deadbolt 2. As a result, this will supercede the SociallySecure example app which showed how to integrate the two.
6. Modules are web-accessible
Modules can be downloaded directly through the browser
7. Modules are framework-accessible
Regardless of the version of Play, and therefore regardless of the dependency mechansim, the repository will serve modules directly to the framework. In other words, when you add modules to dependencies.yml or Build.scala, those modules will be fetched by the framework. Manual installation is not required.
Any logged-in user can vote up a module. One vote per module, to keep things fair.
Any logged-in user can comment. Because of the open sign-in method, I think it doesn’t make sense to have anonymous comments. Trolls can go elsewhere.
10. Play 1 modules
Play 1 modules will be hosted directly in the repo.
11. Play 2 modules
Play 2 modules can also be hosted in the repo, but since they can also be hosted in any Maven or Ivy repo it’s possible to link to the remote repo instead. This doesn’t impact point #7 since it will be transparent to the framework itself.
12. No ambiguity
One very important point comes from Ben Verbeken – “We’ll just have to make sure it’s really obvious to the visitor that they are browsing either the play 1 or play 2 modules (no hidden filter feature, but a big red switch at the top e.g. )”
The github repository (which is currently empty, because it was created nine minutes ago) can be found at https://github.com/playframework/modules.playframework.org
At the moment, we’re purely at the planning stage but I plan to use my favourite development style (evolutionary prototying) to get something up and working fast. The github repo will be created tonight, and regular updates will be posted here.
Peter Hilton has posted some more details over at the Play Google Group.
Java Platform, Enterprise Edition is a widely used platform for enterprise server programming in the Java programming language.
This book covers exciting recipes on securing, tuning and extending enterprise applications using a Java EE 6 implementation.The book starts with the essential changes in Java EE 6. Then they will dive into the implementation of some of the new features of the JPA 2.0 specification, and look at implementing auditing for relational data stores.They will then look into how they can enable security for their software system using Java EE built-in features as well as using the well-known Spring Security framework. They will then look at recipes on testing various Java EE technologies including JPA, EJB, JSF, and Web services.Next they will explore various ways to extend a Java EE environment with the use of additional dynamic languages as well as frameworks.At the end of the book, they will cover managing enterprise application deployment and configuration, and recipes that will help you debug problems and enhance the performance of your applications.