Jaime, let me start by an explanation of planned next steps in modularity/central repository:
Currently we have built Central Repository version 1 with the objective to implement basic/main capabilities of the system. It is planned to define in short functional scope of version 2, that should be put in place by June. Version 2 aims to solve at least the following points: -upgrade/update of core module: Core module is a big one (core.obx file is more than 50MB) and current implementation of obx files delivery is implemented without taking care of performance for big files -managing the maturity of modules: right now there is no guarantee nor info about the quality of modules in the cr -provide a security mechanism (entitlement key) for private modules -support for other Central Repository sites So your email is just in time :-) But I don't think that Mercurial is a solution for any of these features :-( Of course I think that mercurial is great for module developers, but imo Central Repository would not get any advantage from mercurial. Let me explain my points: -I agree with you that updates/upgrades of modules could be done through patches (diff files) to reduce bandwith. But there is no need to integrate mercurial to do that, there are much simpler approaches -A central repository using multiple sites is not solved by multiple mercurial repositories. It is needed to have a mechanism to coordinate those multiple sites to provide a single interface for Central Repository Services (search, scan for updates, get): take into account that a module could depend on in other module stored in a different site -The security mechanism for private modules needs to be "more sophisticated", implemented in Central Repository services (search, scan for updates, get) instead of in the backend repositories of those services. -one main objetive of modularity was to make it simple: developers skills should not be required to operate modularity. Right now a user without developer skills can create new functionality in Openbravo, package it in a .obx file and send it to a friend or publish it in the CR without having to deal with development environments, developer tools and so on. I know that there is a lot of room for improvement to "hide" complexities for our users, but this is the way to go. My point is keep it simple: what are the benefits that we get if we integrate Mercurial in Openbravo? Can we get those benefits in a simpler way, taking into account that our "standard user" is not a developer but a consultant, without strong technical skills? Imo Mercurial is a great tool for developers, but modularity should not be designed for developers but for people in the domain space. I have to prepare the functional spec. and high-level design of Central Repository version 2. I will share this documentation through this list to get your feedback, it will be more than welcome. Regards, Ismael -----Mensaje original----- De: Jaime Torre [mailto:[email protected]] Enviado el: miercoles, 04 de marzo de 2009 23:08 Para: [email protected] Asunto: [Openbravo-development] Rethinking modularity with Mercurial 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 ------------------------------------------------------------------------------ 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
