Hello,
I made some progress on this - mostly exploratory code.
I started making framework a gradle project, removed component
activation code and converted some components to gradle subprojects
(added build.gradle files and "include"ed them in settings.gradle) .
I discovered some interesting things that I think need some attention:
* framework has explicit dependency on libraries that are not specified
in the dependency list - they come from transitive deps (commons-io,
jsoup if my memory is good)
* There are circular dependencies between the components: start depends
on base, base on start and so on. It gets worse as we go to other
components I'm afraid.
* Base does quite a lot of stuff judging from dependencies: json, xml
and html parsing, templates via freemarker, http file upload handling, etc.
It's quite a lot of responsability for a low level component.
I believe some of it could be moved up the stack (http related code is
one IMO)
Code is https://github.com/apache/ofbiz-framework/pull/319 if you want
to try it out.
Next steps IMO:
* Find a way to break circular dependencies in framework components.
IMO this will require:
** moving some classes around
** introducing other components (gradle projects) that will help us
better organize code
* Move to ofbiz application components once this is done.
Like I mentioned above, this is exploratory code, not meant to be merged
as is.
The goals of this exploration is to see how we can
* Migrate ofbiz components to use gradle projects.
* Expose dependencies of each component.
* Expose circular dependencies between components.
* Allow easier future code changes / dependency updates.
I think it is going to be long endeavor but I do think it is going to be
worth it.
What are your thoughts?
Eugen
On 8/6/21 12:30 PM, Nicolas Malin wrote:
Hello Eugeu,
Thanks for this discussion,
I'm a little overworked to read and response quietly. I will try to work
on next week, I plead your patience :)
Nicolas
On 02/08/2021 21:45, Eugen Stan wrote:
Hello,
This is to start a discussion around how OFBiz is being built and see
how to improve the current situation.
Some background:
We plan to use (pitch stage) OFBiz with a client in a cloud setup to
offer warehouse management functionality and more for an existing web
store. The end goal is to help multiple small businesses have an
online presence.
IMO the current OFBiz setup is not very well suited for cloud
deployments. It's quite large, has a lot of components that we don't
plan to use => are a maintenance burden, might (have) caused security
leaks. Some components could be split into another process and scaled
independently: email sending, pdf rendering, batch jobs etc.
Proposal:
I believe that we need to use gradle projects/subprojects and exposes
ofbiz components and plugins as concrete projects / jar libraries.
This is in contrast to how it's currently done where there is a single
gradle project that has subprojects created dynamically from ofbiz
components.
IMO, the benefits would be:
* Ability to publish components as jar libraries to consume in other
projects
* Increase reusability of components and hopefully - more third party
adoption. Ex: ofbiz entity engine could be used outside OFBiz and
improved at a different pace this way
* Modular design - where dependencies for each component/plugin are
visible and may evolve independently (this ties well with java modules)
* Ability for third party to create a custom OFBiz distribution based
on select components/plugins. These can be slim/specialized version of
OFBiz suitable for cloud deployment
* Proper gradle dependency management and explicit dependencies
https://issues.apache.org/jira/browse/OFBIZ-3500 (Think also IDE
support for component projects).
* ?!? I might have missed something.
What changes:
IMPORTANT: These changes will enable users to do more with OFBiz. They
will not change developer workflow that much.
* Create a build.gradle for each ofbiz component in ofbiz-framework
and later for plugins
* Depend on the gradle projects. This means using explicit include
'project-component' instead of dynamically adding them via
settings.gradle / activeComponents .
* Move java dependencies to each subproject
* We can still keep the option to include projects dynamically
* Apache OFBiz does not have to publish the jar libraries, but can
offer support for users to do that
Next steps:
* Provide code sample to build a light OFBIz framework
* Split some components into their own gradle module - to make them
optional: service engines seems like a good candidate (JavaScript,
http, etc)
I am willing to work on this with the community when we reach
consensus. I am not and OFBiz developer so I will need help pushing
these upstream.
Related issues that would be easier to solve
* https://issues.apache.org/jira/browse/OFBIZ-12263
* https://issues.apache.org/jira/browse/OFBIZ-3500
* https://issues.apache.org/jira/browse/OFBIZ-9322
--
Eugen Stan
+40720 898 747 / netdava.com
