Hi,
To support my proposal I have made the changes in this PR
https://github.com/apache/ofbiz-framework/pull/678 .
The code above works:
- "./gradlew cleanAll loadAll testIntegration" - gives me 1 failed test
from 772 (I need help with that one since I don't know how to run itests
in IDE to debug)
- "./gradlew cleanAll loadAll "ofbiz --start" " - works and I can see
DataFile component
== How I got here
I introduced 3 gradle projects:
- base/util
- base/crypto (depends on base/util)
- components/datafile (depends on both the above)
I added dependencies to these projects to ofbiz/build.gradle via
implementation project(':build/util') // ...
Using Intellij "Move class" refactoring I moved classes to one of those
projects.
There where a lot of circular dependencies (for example: class
UtilValidate is using UtilProperties that uses UtilValidate ).
To solve these I use the following technicues:
- Split some methods to a new class and moved that one in base/util: See
UtilFormatOut -> UtilFormatOutBase for example and UtilValidate ->
UtilValidateEmpty and UtilProperties -> UtilPropertiesRuntime
You can recognize these by *Base or *Runtime sufixes.
- Inline some methods - copy one method to a class - creates a small
duplication but breaks dependency cycle.
A lot of time was spent fixing checkstyle errors.
Please please please adopt gradle spotless for automatic java formatting
from gradle.
Using something like google java code formattter you can have the same
formatter in IDE and in gradle cli
- https://github.com/diffplug/spotless/tree/main/plugin-gradle#java
== Where togo from here:
- I would like for us to merge this code ASAP and continue with the
approach for other bits and pieces.
IMO Focus should be on EntityEngine - but every reusable feature
should be split.
- Work can be merged as is IMO (pending some testing)
- Dependencies are starting to be explicit for each project
- We can publish datafile and base/util, base/crypto to Maven repo so
they can be reused in libraries / tooling.
- We need to breake up the cyclic dependencies between classes.
This is A MUST if we want to make OFBiz more modular.
Moving code to a project forces the dependencies to be explicit.
IDE's also have some helpers to detect cyclic dependencies.
Waiting for feedback,
Eugen
La 06.12.2023 01:15, Eugen Stan a scris:
Hello OFBiz devs,
I had some time to check out OFBiz again and I would like to propose
some improvements to OFBiz.
The purpose is to split some independent parts from ofbiz so they can be
used by other projects that wish to interact with OFBiz.
The main beneficiaries will be ofbiz related tooling IMO.
I believe I have identified two initial candidates for splitting:
- datafile component = "framework/datafile" - split as a project /
library - usefull for tooling
- base/crypto -
framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do crypto
in tooling compatible with ofbiz
- base/util - framework/base/src/main/java/org/apache/ofbiz/base/util -
this is used across both of the above stuff
== How the split should happen and how it will look like:
Use gradle subprojects feature to define 3 subprojects in the
ofbiz-framework git repo:
- base/utils
- base/crypto
- components/datafile
The projects will be standalone gradle projects that can be built
individually and have dependencies.
https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html
Since these projects can build jar files, they can be published to maven
to be consumed by other apps.
Since they are projects part of ofbiz-framework, they will participate
as dependencies in the build.
I hope this can open the door to further refactoring and making OFBiz
play nicer with outside developers.
After the change, the code should function the same with regards to
normal OFBIz operations
It is somewhat related to https://issues.apache.org/jira/browse/OFBIZ-3500
--
Eugen Stan
+40770 941 271 / https://www.netdava.com
