Module repository for play

[Guillaume Bort]

So we need to create a module repository for play. A growing community can contribute
these really fast if it's easy to do.

I see these task:

- Create a better documentation page about how to create a play module
- Create a repository on the playframework.org, with the ability to browse modules, register a new one and manage it.
- Create some new play command to automatically list/install/update a module

I think we should take a look at the grails plugin repository which is very great.

[tomas (gugljafa)]

I have a few ideas regarding modules, feel free to ignore them if you don't like them:).
I was using grails plugins for about a year and I didn't like the approach of putting them in a different location than the application path. Reasons are version conflicts, deployment, customizing module for a project and then forgetting that other projects are using the changed version and so on. Also I didn't like that some plugins didn't support uninstall. In case of play, uninstall could be simply deleting the module folder.
Perhaps if there was a modules folder in application, it could be read automatically without having to edit application.conf

[dunsun (dunsun)]

@Tomas

I do not agree. I came from grails too. Yes plugin system or better say versioning system can become tricky but I really think that module settings as it is now in application.conf is great.
It is very simple and one can set path relatively to modules directory where we put (by our convention) all our modules.
If you say - all modules have to be in application's dir - you break modularization approach.
Yes you can put your modules into application's dir if you want ... but do not force others to do it too.
Modules versioning (if one needs it) can be achieved for example through CVS, SVN, ... tagging so I do not see any troubles here too.

[Leandro Pincini (leandropincini)]

I think the better way is install modules into a profiled folder like a ~/.playframework/modules or something like this. And for add svn support on the plugin sitepage or, if it's not possible, you can make something like AUR ( http://aur.archlinux.org ).

[Guillaume Bort (guillaume-bort)]

Why not install them directlty in the modules/ directory of the framework ?

On Fri, Jan 1, 2010 at 1:33 AM, Leandro Pincini
<email address hidden> wrote:
> I think the better way is install modules into a profiled folder like a
> ~/.playframework/modules or something like this. And for add svn support
> on the plugin sitepage or, if it's not possible, you can make something
> like AUR ( http://aur.archlinux.org ).
>
> --
> Module repository for play
> https://bugs.launchpad.net/bugs/459701
> You received this bug notification because you are a member of play
> framework developers, which is subscribed to play framework.
>

[Leandro Pincini (leandropincini)]

@Guillaume

I was thinking about it yesterday.

Then, if you consider Play! can store versions of the modules with a 'gem like' administrator you can store the modules directly on the Play! directory.So you can use the the conf file to import the right version of module for your app or something like that. Or, with ~/.playframework/module directory you can have a system's user with the right version of your module to do this job for you and Play! don't need to manage the versions of the modules in his administrator. Or you still can have a profile in app's conf file who manage this for you. Whatever, you need to think about how you will do to manage the versions of the modules for different applications.

[gedw99 (gedw99)]

I have worked on many module systems.
Once you introduce modules off the main code base you are forced into handling version AND data dependencies.

1. Make sure the Play Module web page can show which module versions work with which play versions. So its a many to many relationship in reality.

2. Make sure the same can be checked from the Play Console. SO its like apt.get basically and handles these dependency relationships for you, and tells you that upgrading X, means that you MUst or CAN upgrade moduel a, b and c.
If you do item1, then item 2 is possible because you have the relationships moduled :)

Then you have the data dependencies. Some systems use a Base Entity in the Main code base, and a derived entity in the module code base. When this is done you now have a data dependency in the database between the Play framework and the modules.
If you dont have this its much easier, but you may.
If you do, then you also need data migration scripts UP and down versions.

In general it makes life allot easier for the developers of the play framework if there are no data dependencies between the Framework and the Modules.