Neogia addons-manager is very young, only one year, so some technical
parts should be enhance, but I don't think it's the more important point
of discussion.
Why addons and for what ?
Which constrains for a addon for being publishable ?
Currently in Neogia, we are trying to answer each of these questions,
step by step, with real use case, and enhance technical or process part
at each step.
Today, we can say :
Why addons ? :
- technically, it's better to have a kernel with a lot of software
rather than a all-in-one software (like unix): evolution is more
dynamic, maintenance is more easier, global system is more stable
- licence, with all-in-one software, only one licence type is possible,
not possible to have together free software and commercial software,
published and easily installable and usable
- business analysis, it's more easier to describe one business function
(business coverage, Help, junit and functional test, demo data ) when
you are concentrated to only one business Use case.
For what ?
- technically, OFBiz is a strong technical framework, but some people
want to use (or uses) some special technology (GWT, Flex, hibernate,
...) but they don't publish their work.
- - It will be more usable for ofbiz community for test or evaluation if
ready to use code is available.
- - It will be easier to those people to contribute to standard OFBiz
framework if their works are clearly separate, so OFBiz enhancement will
appear clearly
- business, why having multiple functions which are not used, if one can
install only what he wants, screens, forms menu and processes will be
clearer and more usable
- OOTB (Out Of The Box), one of the main goal of OFBiz Project, is to be
able to realize quickly an end-user solution. Add-ons can be used to
package this type of realization.
Which constrains for an addon to be published ?
- First of all, ensure consistent among ofbiz and all other addons. This
will be possible only if community is able to read, test and validate
addons, exactly like a current classic contribution. So, it's necessary
to add some constrains in addon realisation :
1) Addon help file is mandatory with
1.1) business coverage if it's a new business function
2) Test process with description, unit test and integration test
- for which ofbiz version release it has been tested
- list of addons (with version) dependency
- clear license and owner
Addon manager and developer
The main goal for addon manager, on the developer point of view, is to
give tools to extract and package development when it's finished, with
the minimum of development constraints only respect the OFBiz best practice.
Current addon-manager version and patch
Currently with OFBiz, there is a lot of cases where it's possible to add
files to put a modification. This is the best way, but sometime it's not
yet possible.
In the current addon manager version we are using "classical" patch to
store files modified, but there is some enhancement to manage more
easily multiple patchs on same file.
We want to have "xml semantic" patch, but our work on this is only at
the beginning, currently it's not a high priority because it's not yet a
problem with our 66 existing addons. We know that it will mandatory, but
one step at a time.
Next steps for addons
Currently in OFBiz project, there are framework, applications,
specialpurpose and hot-deploy. extend exists in a lot of place, so there
is no emergency to change existing organization, the main modularity
rules are already in place, We should use new functions (technical or
business) in addons to test all the process (development, usage,
installation, maintenance, version migration, ...) for being more
modular and see if those evolutions are good for the OFBiz project.
Maybe sometime, new extend functions will be proposed during addon
testing period
When community will have tested and approved this new organization, we
will start studying in the current ofbiz version which functions
(technical and business) should be in kernel and which should be
transform as an addon.
Malin Nicolas a écrit :
Hi David,
Neogia addons-manager isn't only a series of patches. The dependence system
allows to create addons with orientation :
* technical (ex : multi-delegator, pdf-view-handler) : improvement on ofbiz
technical framework
* functional (ex : oisg-status, company) : imporement on ofbiz functional
framework
* end-user application (ex : naccounting, nmanufacturing) : add standard
OFBiz components
In general, we have a end-user appication that content dependency on
functional and technical addons.
If two addons change the same code, there is a architectural problem, we
need create a new addon who manage the conflict reason. If two addons
change/add code on the same area, the addon-manager detect and resolve the
problem.
The actual OFBiz components system is good but when you need improve the
functional system, is difficult to submit your enhancement, need test on
your components, after update on OFBiz framework and try to explain it for
validation. In most case, if you aren't a commiter you take your functional
enhancement in your component and it's not integrate in OFBiz functionnal
and can't use for other compenent without create dependency in hot-deploy or
specialpurpose.
With addons, all functional enhancement are put in specific addon and it use
for many end-user addon. After it's more easier to create a jira for
integrate in OFBiz framework (after we juste remove addon dependency ;) )
OFBiz Why not become the first modular integrated ERP with a library
addition to management as a debian (we have a functioning distribution
management company;))
Nicolas
