Hello Nicolas,
Thank you for looking into this.
I know it's not an easy task.
I believe that where is a will, there is a way.
Now let's see if the OFBiz community has a strong will in this direction.
Let's discuss about your proposal and let's see where it goes.
See my comments inline:
On 02.09.2021 17:43, Nicolas Malin wrote:
Hello Eugen,
On 30/08/2021 11:48, Eugen Stan wrote:
Hello,
I've opened a new issue
https://issues.apache.org/jira/browse/OFBIZ-12309 .
I need community help with this.
I analyzed at fresh head, It's a hard task to remove the circular
dependency.
Yes it is :(.
We have some dependencies that would be easily to remove (and some
introduce by myself I realized by misunderstanding or weakness of mind)
and some other that have their own reason.
If we want to go on increase the scalability, I search if the effort to
scale at each component is coherent with the most-valuable to win.
I'm mostly concerned with project maintainability and innovation - both
are hard to do in a large project with unclear dependencies.
I have on my mind to elaborate a framework-core an acceptable minimal
circular dependencies and some other present as three dependency
* core : common - base - start - entity - service - security - webapp
* entityext : core
* datafile: core
* testtools: core
* catalina: core
* widget: core
* webtools: widget, testtools, datafile, catalina
I know this isn't your final objective but can it be an acceptable spot ?
Thanks. It's a very good place to start.
We might be able to introduce a 'core' gradle project that contains
those and depend on that one in the others.
I would move out start module.
It seems to be responsible for starting up the app.
I imagine components have an interface (the Container).
All ofbiz plugins/modules implement this so there should not be a
dependency on implementations.
Perhaps this is a good point to start - separating the container and
depending on it in other modules.
start will start ofbiz and load modules list from xml + look them up on
the classpath.
WDYT? How would the list above change with a container API module?
Another helpful thing is to establish the boundaries of each project.
What should each module do and what it should NOT do?
I think a lot of things will clear up once that is established.
The functionality that does not fit in the module/project should be
moved elsewhere.
Can you (or anyone else) (please) provide some lines as to what should
each module in framework do and NOT do?
Eugen
Nicolas
From the exploratory
branch https://github.com/apache/ofbiz-framework/pull/319 I
discovered there are a lot of circular dependencies between components
(components depending on each other in order to build).
I believe it would be very useful to have a logical dependency tree
between components.
As a developer working to make OFBiz usable as a framework I need to
solve issues like circular dependencies between components
(see https://issues.apache.org/jira/browse/OFBIZ-12308 ) .
This should serve as a guide to help me decide how to solve the
circular dependency issue.
This is the current list of dependencies in framework (applications
should be in another issue IMO).
<load-component component-location="base"/>
<load-component component-location="entity"/>
<load-component component-location="security"/>
<load-component component-location="datafile"/>
<load-component component-location="minilang"/>
<load-component component-location="common"/>
<load-component component-location="service"/>
<load-component component-location="catalina"/>
<load-component component-location="entityext"/>
<load-component component-location="webapp"/>
<load-component component-location="widget"/>
<load-component component-location="testtools"/>
<load-component component-location="webtools"/>
Related work:
* https://issues.apache.org/jira/browse/OFBIZ-3500
*
https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+9.04
*
https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04
Looking forward to feedback on this.
Regards,
--
Eugen Stan
+40720 898 747 / netdava.com
