Back in November, I spoke to Nicolas Leroux of the Play framework about creating a module repository. He agreed it would be a good idea, but lack of time has prevented me from starting this. Following the stormy events of last week in the Play Google Group, I’ve decided to prioritise it. A working prototype should be available in a couple of weeks.

The overview:
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.

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

8. Voting
Any logged-in user can vote up a module. One vote per module, to keep things fair.

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

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.

5 thoughts on “The all-new Play Module Repository

  1. great news!

    congrats steve, I’m sure that with the help of the community you’ll do a great job

    I would also add tests as a requirement! If it’s not applicable, the author of the module should at least implement a dummy test to pass thru, or at least make it optional but show a big red sign if it’s missing.

    – Another feature that we discussed it’s usage and download stats…
    – versioning (like the current module manager)

    BTW, are going with java or scala???

  2. That’s nice.

    1) Do the modules have to be open source too? Are binary uploads allowed?

    3) >a license (preferably, but not constrained to, >a business-friendly one)
    So this phrase eliminates itself. Closed/gated source license too?

    2) Do you play with Java or Scala?

    12) The complete version should be visible on the button, not only “2” but “2.1.3”. It should be clear with which version of Play a module is tested to prevent somebody installing a module for 1.1 in 1.5 for example.

    Would there be a predefined version scheme for modules?

    Should there be a workflow for a module version, like [uploaded|in review|execepted,retired, …]?

  3. Hi Sun,

    1. This point is something for discussion.

    2. Play 2 treats Java and Scala as first-class languages. Modules can be written in whichever language you prefer. The repo manager itself will probably be a hybrid.

    3. Restrictive licenses are allowed – this is something that’s entirely up to the module developer. The pros and cons of restrictive licenses are well-known, so I’m not going to go into them here. I mentioned business-friendly licenses specifically because those modules have a much significantly higher chance of being used in a commercial environment, which broadens your target user base a lot.

    12. Each module will have versions, and those versions will explicitly state their compatibility with various versions of Play. This is essential, given that both Play 1 and 2 modules will be present.

    A version scheme will be suggested, but can be arbitrary.

    I don’t think there will be a workflow because there won’t be a review/acceptance process. There is one at the moment in the existing Play module repo, and I think it’s held up a lot of modules being added simply due to the amount of work required to review and publish them.

    One of the key points to the new repo is that modules are managed entirely by the owner. A combination of comments and votes will provide feedback.

  4. Much needed!

    Could the repo location be added to the latest Play! 1.x so that we can continue to use dependencies.yml?

Leave a Reply

Your email address will not be published. Required fields are marked *