Hi Jaime, I think it would be good if we can split core up in smaller modules. Also we should look at the size of Openbravo in general. It is true that we have one central repository. Imo we should really make it possible to either divide the central repository in separate sections or support multiple repositories. Having multiple repositories seems the better solution imo.
Afaics the current openbravo core is not really a module, from a folder structure perspective. Modules are contained within their own subdirectory within the modules directory. This is not the case for Openbravo core. So I am not sure if that makes it more difficult for Mercurial. While reading your post I went from a golden hammer feeling (we now use Mercurial in Openbravo, let's use it everywhere... :-) to the feeling that it is elegant to distribute openbravo software artifacts using the same mechanism as we use in our development process. In the end my feel is that you are correct that there are for sure many advantages in using the same mechanism as we use in Development to make updates available to customers. Especially because we typically don't distribute binaries but we distribute source code and build on the customer's system. Things what I see as drawback/obstacles: - integration between java (client side) and Mercurial and the technology we use on the central repository and Mercurial, how difficult is it/how much work is it - Openbravo has already invested in a central repository using a different technology...., so how likely is it that we can change this at this point in time. - Need to install extra components next to Openbravo. For the central repository (based on Mercurial or not) there are ideas for the following improvements which should also be taken into account: - only allow access to certain modules after payment for a licence - limit access to a module for a certain period (allow all updates within a year) - make a distinction between certified modules and non-certified modules Part of this can be done with separate repositories for other parts we need like a separate app to track all this. This separate app would then need to be tightly integrated with Mercurial to revoke and envoke authorizations and user names. Note that it is not necessarily more work to develop this functionality integrating with Mercurial or not integrating with Mercurial. gr. Martin Jaime Torre wrote: > 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 > > -- With Regards, Martin Taal Openbravo M: +31 6 288 48 943 @: [email protected] Skype: martintaal Openbravo Headquarters: P: +34 93 27 25 947 F: +34 93 27 25 905 Address: Edificio Slan, Planta 2a, Landaben, Calle J, 31012 Pamplona, Navarra, Spain Mailing address: PO Box 5117, 31010 Pamplona, Navarra, Spain ------------------------------------------------------------------------------ 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
