Hi all, On Thu, 2 Dec 2010 11:53:00 +0100 Juan Pablo Aroztegi <juanpablo.arozt...@openbravo.com> wrote:
> Core is not of use by itself, it needs other modules to > work. If Core is not of use by itself, why we don't make useful? To me is clear that if Core can't work without these 'base' modules, this ones are part of Core. We don't need to have a different code repository for them, nor having them under the modules folder. These 3.0 base modules should be part of 'src'. If we start doing things like, defining dependencies of Core on other modules we are breaking the rule of 'Core' _is the base module_ and the starting point of the rest. I know that we support this type of dependencies but, to me, makes no sense. My proposal: * Place all the code from the 'new architecture' modules (weld, kernel, smartclient, client.application, etc) into Core, and leave the module repositories for bugfixing and supporting 2.50. Remember that we support the 'New Selectors' in 2.50, and these module use this new architecture. With this approach we follow the same defect/backport strategy. If we need to fix a defect, we solve it in 3.0 code line, and then (if necessary) backport the change to the specific module repository. * Core 3.0 'merges' all this modules. When upgrading a 2.50 instance to 3.0 all the required stack is part of core, so the modules will get deleted. Let me know what do you think? -- Iván Perdomo ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development
