Hi Ron,
It's interesting, and I agree with you we must organise the project and ourselves
"more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for now, this
one is about specialpurpose components :)
Note that another baby step we have already decided on is to group the
applications data model in one component.
This should hopefully clarify things at the applications level. I think most
dependencies are due to the data model, but I'm not quite sure about that.
Jacques
PS: BTW I just found this article interesting http://breakingsmart.com/season-1/rough-consensus-and-maximal-interestingness . Seems that there are a
bunch of others as interesting there.
Le 14/12/2015 16:47, Ron Wheeler a écrit :
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
