Hello Taher,
Thanks for getting back.
I think we are very much aligned on where we want to go but we have
different perspectives on where we are in regards to OFBiz.
I will motivate my reply inline:
On 29.11.2021 10:36, Taher Alkhateeb wrote:
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.
I disagree with your statement above.
From my experience ofbiz is not split up in separate modules.
If you read https://issues.apache.org/jira/browse/OFBIZ-12308 and
comments from https://github.com/apache/ofbiz-framework/pull/319 you
will see what I mean.
There are circular dependencies between modules - so they are not split up.
Also if you look at https://issues.apache.org/jira/browse/OFBIZ-12263
you can't build plugins that use other repositories, unless you add
those repos (and I believe also dependencies) to OFBIz.
Basically you can't publish binary plugins easily IMO.
In order to fix these I believe we need to use gradle sub-projects and
have a full fledged build.gradle in each directory (full fledged gradle
project) complete with dependencies.
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.
I do agree we should allow multiple aggregation of these modules in
different configurations.
That will allow us to build custom OFBiz distributions.
As I stated in https://github.com/apache/ofbiz-framework/pull/319 , this
is not possible since modules are interconnected (circular dependencies)
and you can't split them apart.
You can't publish and independently use framework/entities or services
or base because they use classes from each other.
Also the gradle build system is highly customized and hence not very
friendly to new developers because - since they need to understand the
1000+ lines of custom build code.
My proposal on this part is to:
* Drop dynamic project add via activeComponents (maybe keep for plugins ?!)
* Use standard build.gradle in every project - static project composition
* Gradually refactor code -> move dependencies into each sub-project
* Deprecate framework/start and replace with top level ofbiz-start
gradle project that will depend and aggregate ofbiz modules and build
the app. This will be the deliverable and also example on how to build
your own ofbiz distribution.
People should be able to customize or create their own copy of this
project to have a custom OFBiz distribution with whatever modules and
configuration they desire. If we publish jars for modules, this project
could be anywhere on git(hub).
Cheers,
Taher Alkhateeb
Regards,
--
Eugen Stan
+40770 941 271 / https://www.netdava.com
begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard
