> - Concerning labels management, the creation of an extension for rarely > used languages would allow to not load all languages in OFBiz.
I am not sure what this means, but the only languages that are "loaded" (kept in memory) are the ones that current users have selected.
Adrian Crum Sandglass Software www.sandglass-software.com On 9/5/2014 9:34 AM, Responsable de groupe wrote:
Hello, We have recently created an association in order to promote OFBiz in Francophony (France, Belgium, etc.) For that purpose we would like to build with the community an integrated tool which allow to manage extensions (add/modification of source code or file, dependency/compatibility). OFBiz already offers extensions tools, but in some specific cases, these tools don't fit completely, they miss some functionalities. The realization of an extension manager is motivated by the following reasons: - Need of pre-parametered solution in one domain - To offer a possibility for companies to extend OFBiz, identify their addings, manage their own modifications (because not integrable in trunk for licence reason, code quality or simply by choice). This can be done by creating modules in their OFBiz development, ie by identifying, grouping and managing the different parts of a development. - Simplify contribution tests and exchanges by standardization of installation (same install system for: patch, patch + add of file, or component hot-deploy + patch) - Industrialization of development/quality control and projects environment methods. Two cases can illustrate the utility of an extensions manager: labels management and framework modifications: - Concerning labels management, the creation of an extension for rarely used languages would allow to not load all languages in OFBiz. - Concerning framework modifications, it should be able to supply an extension allowing to modify non-overloadable labels, like entities labels. The Nereide company, a member of the association OFBiz-France, already tried to build such a tool, but did it without prior exchanges with the community. So, there is an available POC. It contains some gaps (no cross-platform, no external tools used), but this tool partially fills our first needs. Using this tool allows to no longer develop in a monolithic way for each customer, but to split functionalities by modules, reusable in several projects. It is very useful for industrializing methods of development/receipt and for launching in production OFBiz based projects. We have a good feedback of experience which reinforces our convictions to go further on this kind of tool. We are firmly convinced that it should be very helpful to increase the use of OFBiz in integration companies. This notion has nothing original ..., no ? (just take a look to the "competitors": Magento, Odoo, etc.), but we think this is the first step to make OFBiz really modular. Making an ERP modular is something complex but desirable. Others before us succeeded in this complex task, we think in particular of PC operating systems such as GNU/Linux. To go further, we have realized a first specification on the expected functionalities of an extension manager : *** It has to be able to get back extensions from previously identified deposits. *** It has to easily identify any modifications done on OFBiz (with or without extensions). *** It has to be able to choose, in an autonomous way, the best solution of storage according to identified modifications. For example: * Add/Remove code in a XML DOM. * Add/Remove code in a text file: line or semantic (method in Java class) * Add/Remove text or binary files The chosen storage solution must be as strong as possible. It should make extensions resistant to the evolution of OFBiz arborescence and to potentially conflicting modifications of other extensions. *** It has to preserve the formatting of lines which are not modified (indent, attributes order, etc.). *** It has to authorize adding, then removing a modification, while leaving OFBiz arborescence in its initial state (in particular by deleting added folders). Process must be clean and so reversible. *** It has to be self-sufficient and time-honoured. The tool must generate clean files of adding/modifying. *** It has to allow cross-platform patching. All must be realized through Java (or any other cross-plateforms solution). For example by using Patch source code of Eclipse, Netbeans, etc. *** It has to propose a set of functionalities for extension management (release number, release log, etc.). *** It has to be very simple of use in order to be quickly taken in hand by developers novice to this tool. *** It has to manage dependency between extensions. It must allow separation of modifications which could potentially be used by several extensions. *** It has to manage the extension documentation (list, add, remove). *** the notion of pre/post installation process (target ant) of the extension could be useful (launching junit, tests, automatic data loading, etc.). *** It has to be usable as command line such as OFBiz webapp. This is only a working base to begin a discussion allowing everyone to express his opinion and to bring ideas in order to build together a reliable and complete tool. Prepare your critics, looking forward for your answers :) Group manager of Contributions workgroup OFBiz-France
