Modularity is a great new functionality in 2.50 and is probably a key factor for the success of the forge and the eco-system we want to build. However, I have been told that it has some limitations that stop us from giving the best tools and services to our users. The two biggest drawbacks are: * Downloading a core update could take several hours. As an update means downloading the whole module again and core is a big module, it can take a lot of time to download. That means that every time a customer wants to apply a fix that we have provided, it will need several hours to do the update (no matter how small the fix is). * There is only one central repository. We would like to provide a tool for partners that acts a module repository that serves module updates to their customers. Currently this is not possible because modularity is designed to work only with one central repository.
I have come to a solution that solves these issues. It may too have some drawbacks and I need your help to find them. The idea is to manage modularity through Mercurial repositories. The interface the user would see would be very similar to the current one, but internally Mercurial would be used. A module would just be a Mercurial repository with all the needed source code and a file containing information about the module (e.g., name, description) and its dependencies. The versioning of the module would be done through Mercurial tags. What we now call Central Repository would be substituted by a set of repositories containing each a different module. For example, the modules could be served under http://code.openbravo.com/erp/modules. When a user registers a module, a new repository is created under erp/modules and the user is given push access to it. Take into account that there could be more module repositories than this central one owned by Openbravo. >From the user point of view, there are two things that would change in Openbravo ERP. First, the user could define one or more addresses where to look for updates. The default would be http://code.openbravo.com/erp/modules, but the user could also add unofficial module repositories (e.g., http://mypage.com/mymodules). Second, a user could install a module by adding directly the complete url to the repository (e.g., http://mypage.com/mymodules/testme). When a user installs a module, a simple clone is done. When updating a module, only a pull is needed; that is, only the latest changes would be downloaded. All the dependency resolution would be done in Openbravo ERP, making the repository as 'dumb' as possible. This solution solves the two problems described at the beginning: * The download of a core update would be done really fast, as it just has to download the latest changes done in code. * It would be really easy for partners to serve their customized modules to customers. Customer would just have to configure the module repository url address in their Openbravo Installation. Additionally, there would be some more advantages with this solution: * Anyone could serve their own modules. This could be done through the internet, but it could also make sense to do it inside a network to share developments between developers. * It is posible to have private modules. The only thing needed would be to configure the module Mercurial repository accordingly and to define a user and password in Openbravo ERP. * Module management is simplified. Developers don't need to generate .obx files nor send them. They just have to work with Mercurial (a recommended practice anyway) and they are already able of sharing and serving the module. Update of a module in the Central Repository would be done by just pushing a new tag. Please let me know what you think about this. Regards, Jaime ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Openbravo-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-development
