It seems that this discussion is just dancing around the core problem
with the current structure of OFBiz.
There seems to be a natural set of almost separate projects that are
lumped together into a rather tangled object.
This discussion is nibbling around the edge of the problem rather than
addressing the problem straight up.
To get to the next level of product maturity, we need to find a way to
break the product into manageable pieces with well defined rules about
how it gets extended and how "new" features get integrated.
The framework should be the first to get untangled since that is
supposed to be a separate product.
This is in progress but it not yet clear what the relationship will be
between the new framework and the old one or even OFBiz.
At some point, the leaders of this project are going to have to decide
what is the core ERP application. This means separating:
- core functionality
- core seed data
- seed Data for particular industries or
- demos
- optional application modules
Then there needs to be rules about how new things get added.
Breaking up the people who can commit to each area will add a bit of
discipline to the process.
At the moment any committer can change every level of the structure to
accomplish their goals.
This is very efficient for the person wanting to add something but
creates havoc for the project as a whole.
Getting to a point where releases of individual components can be made
without having to release everything at once will have a lot of benefits
and make it easier to maintain an OFBiz installation.
If you can upgrade the framework without updating the ERP, framework
improvements can be made more rapidly.
If the core ERP can be upgraded without having to worry about every
"special purpose" component ever created, it will get a lot easier to
get releases out.
This means that there will have to be rules and real APIs that you can
not violate.
It will also mean that people wanting to change things that require
changes to multiple levels will have to actually discuss their proposal
and convince the framework team or ERP team to add the required
functionality and test it to make sure that it does not break the API.
This will also increase the potential for community involvement.
Currently, it is too risky to add committers who only want to work on
one module or even a demo since there is no way to stop them breaking
lots of things accidentally.
Ron
On 14/12/2015 1:01 AM, Jacques Le Roux wrote:
Le 08/12/2015 20:59, Nicolas Malin a écrit :
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
Could we list, apart the well known Birt issue, special
components which
are overriding main applications?
Directly by memory, the scrum components has defined new seca on cust
request to send email that break the standard customer request system
An other where I failed, used service findProductsById instead of
findProductById, the first from hhfacilty and the second from
catalog. And
want you start your hot-deploy component without specialpurpose
... paff !
:)
Thanks for these points Nicolas, I agree with Pierre suggestion.
For instance does really the hhfacilty findProductById service needs
to be named the same than in product? Etc.
Of course I'm also for this, but the problem isn't on the capacity to
open a jira issue.
Nicolas
OK, I had an idea. Why not commenting out the specialpurpose
components by default, but uncomment those which have proved to "not
be a problem"?
"Not be a problem" means here which are not overriding applications
component. So we could create a "Comment out specialpurpose components
by default" Jira
with possible subtasks for litigious cases (when we find an issue
after uncommenting out)
I suggest though that we don't do that on trunk (which would still
contains all components active) but on the next frozen release. We
could even do it on R14.12 if we have a consensus.
To start, I'd at least uncomment out:
example
exampleext
pos
ecommerce(? if not OK then we create the main Jira and a subtask for it)
Adds your please...
Opinions?
Jacques
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102