Hi Eugen,
I was still not able to review your efforts in-depth and I am most
likely not able to do it in due time.
So here are some general thoughts.
Regarding the scope:
1. I am in favour of doing refactorings which are for the good of the
Apache OFBiz project itself, e.g. removing circular dependencies and
other flaws in the general architecture. To decide on those work items,
we have to split them in working packages, describe the goals and
implementation plan and discuss / decide if we want to do it in the project.
2. I am strongly against doing more refactorings which do not bring an
advantage for the project and its users itself. For example, I do not
see an advantage to make the entity engine a library which can be used
in other projects/eco systems.
Those are massive changes, a lot of work and it likely will bring up new
users who have no interest in Apache OFBiz itself but in the entity
engine part. And they will ask for features which are not beneficial for
Apache OFBiz. We already know that we are short on volunteers to
maintain the project, let alone additional libraries. We also have had
experience with volunteers trying to change everything at once and who
suddenly vanished from the project, leaving the effort in an unfinished
state. That's a risk we have to put into account.
On the other hand, Apache OFBiz users are looking for features,
stability and security, their benefit from those changes seems very
small for me.
In our project, we should focus on the project to make it better with
architecture, functionality and security etc. and deliver new releases
for the users base in a more plannable way, but I strongly advise not to
put too much burden on our shoulders with side projects.
To stick to the example: if someone wants to have a capsulated entity
engine library to drop in into any other project, this should be a
separate project.
Regarding the development approach:
1. we should definetely do massive code changes in the core architecture
in feature branches and not in trunk. We are heading towards a more
stable release roadmap with new release branches every year and if
development on those changes is stale we will have a problem. So I am
not seeing a massive PR merged into the codebase at once.
2. if we can focus on more tiny bits of change which can be delivered in
a overseeable time and risk, we could decide to do them in trunk.
3. those changes should only be merged into trunk after extensive testing.
4. we should focus at one bigger code change at a time and not do more
in parallel so that we have enough ressources to review / test them and
focus on the general project / roadmap also.
To sum up: I appreciate your efforts on doing Apache OFBiz better and
support those efforts if we can agree on a doable approach. However, I
am in favor of a clear demarcation from changes that do not benefit the
project itself.
I hope I have explained my thoughts well enough,
best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 06.09.24 um 17:46 schrieb Eugen Stan:
Hello,
It's been some time :) .
I saw the new release is about to happen and I was wondering if there
is interest in moving forward with making OFBiz modular.
I am willing to split the big, scary PR in smaller bits that can be
adopted / followed more easily.
https://github.com/apache/ofbiz-framework/pull/678
But I am looking for a sponsor/champion to work with me and get them
merged in OFBiz.
I don't want to work that is wasted - otherwise I would spend my time
and energy elsewhere.
The plan would be:
- introduce empty gradle projects, one at a time
- move classes in smaller batches to these projects while keeping
tests runnig
In the end we should have a few ofbiz libraries there that can be used
from outside: like org.apache.ofbiz/component-datafile/18.12.10
Once this is done, we can re-evaluate the road ahead.
IMO the next milestone is to split entity-engine as a library so apps
could read OFBiz data straight from DB - this should take OFBiz
integration to a next level.
After that go for service-engine and after that for the applications
themselves - but it's too far from today to know how things will look
like.
So, who is willing to move ahead with this spend some time and review
some PR's and merge them ?
I did see interest in the past from Jaques, Nicolas and Daniel :) .
Regards,
Eugen
La 22.03.2024 20:03, Eugen Stan a scris:
Hi Nicolas,
Thanks for the support. I do hope we get the ball roling at one point.
I won't be attending ApacheCon this year.
I think it's been 13 years since my last ApacheCon :).
Feel free to start merging changes.
Regards,
Eugen
La 22.03.2024 18:23, Nicolas Malin a scris:
Thanks both for your work and analyze !
I agree on the first point, we need to move forward to release the
next OFBiz version and after we can breaking the wall :D
If the person are present at the eu apachecon it would be nice place
to start a workshop on face to face ?
Nicolas
