Hello,
I may be misunderstanding your point, but ofbiz is already broken down
to sub-projects and the sub-projects are defined from the framework
itself (check common.gradle). And it is possible to publish ofbiz parts
separately, and also possible to isolate dependencies in each project
and it is already done for some components. We also do already have a
plugin mechanism that allows you to publish things separately.
Maybe there is little value now in working on Gradle beyond basic
maintenance. The real hard-work that is probably badly needed is in
breaking down the components themselves into layers that makes it easy
to extend the framework at multiple levels. And to get rid of many
things that piled up over the years. If you can get the system to work
well at each of the below layers then extensibility might become an
easier problem:
1. framework
2. data model -> framework
3. data-model services -> data -model
5. data-model UI -> data-model & data-model services
6. applications (I don't mean accounting, party, but rather a full
application that utilizes the above layers)
7. plugins (pick and choose whatever layers needed)
My 2 cents.
Cheers,
Taher Alkhateeb
On 11/29/21 03:28, Eugen Stan wrote:
Hi,
I think I made some progress while reverse engineering how ofbiz is
built and I decided to share this so on the issue
https://issues.apache.org/jira/browse/OFBIZ-3500
My train of thought is to split the current setup first into 4 static
gradle sub-projects:
* framework
* application
* themes
* plugins - we should add plugins dynamically first.
Each sub-project should have it's own dependencies {}, source-sets {}
etc.
We can then depend these sub-projects in the main project.
Benefits we get from this change:
* we get closer to publish ofbiz parts as libraries .
* we get closer to smaller components - which are easier to maintain
* we get better dependency management - and closer into splitting the
ofbiz monolith into smaller services
Please let me know how you feel about this.
