Re: OFBiz re-architecture thoughts

[Sakthivel Vellingiri]

Thanks Taher and Michael for detailed insights and Sathish for sharing your
thoughts on upgrades.

Just to introduce myself, we are using OFBiz for little over 7 years for a
Life Sciences Product, and we consider ourselves as end user and haven't
inclined to make hardcore changes to the framework as yet.

1. Lack of Code Isolation_:::
 Our approach has been as outlined by Michael, we have custom plugins
for each application and in some cases custom application plugins for each
customer which are overrides and extensions of the OOTB OFBiz application
plugins and we more or less leave the framework untouched except for a few
issues we have discovered, and we are guilty of not contributing the fix
back to OFBIZ and hence maintaining in our own branch, but without taking
an inventory now, my recollection is that the changes to the framework is
minimal. we merge the changes from our customer application plugin branch
to *our* common application plugin branch that way *our* common application
plugin branch at a given point in time has most of *our* custom application
plugin changes.

2. Rest Interface:::
We are currently using HTML based web UI and relying on
widget/freemarker templating for the changes. We are inclined to client
rendering using Vue Js, and having Rest API integrated in the core
framework would be a huge plus. but we are open to using Rest API as a
plugin to begin with, I know there has been some communication around Rest
based webservice api in the email thread, I have to admit, we haven't
explored that all that much yet. But if a Rest API plugin is made
available, we will be happy to utilize that and share feedback.

3. UI Screens:::
As experienced by new users and outlined in this thread, we end up
customizing the UI to minimize the field display to our user needs either
by making changes in minilang or ftl, Perhaps it might be good idea to have
database tables to control what is rendered in the UI and perhaps rendering
based on database configuration can include support for role/permission
based rendering to show different fields for different
roles/SecurityPermission.

4. Webapps :::
   As of right now, we switch off the webapps that we do not need
currently, At less frequent times we see application logouts when switching
from one webapp to another, i'm not sure if this caused by having different
plugins as different webapps and passing the session id between them and if
this be solved by having single webapp, but i do not understand enough
about the merits of having a single webapp at this time to comment more on
this.

I do not have strong opinions about the other points other than what is
discussed already and i will skip responding to them,

In my opinion replacing OFBiz framework code with established open source
which is  purpose-built for a specific use case like Apache Shiro for
Security, eHCache for caching could  bring down OFBiz framework code and
thereby maintenance of OFBiz, framework however i also recognize and
reflect the thoughts outlined in this thread that we need to be very
careful about bringing such hardcore changes with careful planning &
quality control not to disrupt the existing implementations.

Thanks to everyone sharing their view points and starting a conversation in
lieu of the future of OFBiz.

just my 2 cents from the end user perspective.

regards
Sakthi


On Mon, Dec 27, 2021 at 1:09 PM Taher Alkhateeb 
wrote:

> Hi Michael,
>
> Thank you so much for spending your time reading and sifting through
> everything, I really appreciate and value your feedback.
>
> I need to highlight that we deployed mixed and somewhat crazy solutions
> including multiple mobile apps, live video / chat streaming systems and
> other projects that are booming in Kuwait and exploding both in user
> bases and technical requirements which is why we cannot operate some of
> these projects the way we used to in the past.
>
> Anyway I think I'm not going to elaborate too much as we wait for more
> opinions from the community to see if this is worth pushing. However, I
> want to reply to a few points you raised:
>
> - There is a huge difference between _few_ modifications, and ZERO
> modifications to the framework or core components. This way you don't
> even need to freeze a version of OFBiz to develop against at all!
> - Breaking to multiple git repositories means having something like
> ./gradlew gitPullAll to update and you're done. Nothing breaks, no
> surprises. You have to try it to believe it :) I have client projects
> that have 15 git repos and I can upgrade with my eyes closed. Also there
> is always entanglement that you don't feel or care for until you
> actually cut the repo into pieces and then realize we have too much
> entanglement. Having many small git repositories is in fact the most
> enjoyable part of how we're writing software now and I can assign
> different modules to different teams and they work independent of each
> other. It's just a totally 

Re: I'm working on an OFBiz helm chart for kubernetes

[Sakthivel Vellingiri]

Hi Eugen - This is a wonderful effort, i would be interested in using it
when available and happy to be part of the testing effort, pls share any
updates you might have, i have a Windows Environment running Windows Server
2016,  Ubuntu Server running Ubuntu 18.04 and Ubuntu Desktop running 18.04,
and i can help test in these environments.

On Sun, May 9, 2021 at 3:13 PM Eugen Stan  wrote:

>
>
> Hello,
>
> NOTE: I previously sent this email from an un-subscribed email address,
> please ignore that one.
>
> I'm working on a Helm chart for OFBiz
> https://github.com/ieugen/charts/tree/main/ofbiz .
>
> The goal is to have OFBiz running in Kubernetes.
>
> Right now it's a rough start: it starts OFBiz with Derby and that's
> about it.
>
> I'll keep pushing updates as soon as I have them.
>
> I'm interested in your feedback.
> If you plan on testing it and using it let me know.
> I do accept and encourage collaboration.
>
> If this is interesting I might push it upstream but it uses the binary
> build of OFBiz in Docker.
>
>
> I'm using docker images built from trunk on jdk-11.
> There are amd64 and arm64 (Raspberry PI4) images.
>
> Some issues that need solving are the many configuration files that
> OFBiz has.
>
> This details creates a lot of configuration when deploying in Docker /
> Kubernetes as they need to be mounted in a volume with many entries or
> multiple volumes.
>
> There are many potential solutions to this but it boils down to:
> * It would be nice to load max 1-2 or 3 configuration file with multiple
> sections instead of the currently many configs split over the code base.
> * It would be nice to support configuration (overwrite) via ENV vars for
> some things like DB connection.
>
>
> Regards.
> Eugen
>

Re: Adrian Crum

[Sakthivel Vellingiri]

This is very sad news .

I met Adrian in ApacheCon last year at Austin Texas, I still remember, I
was the first one to go in the room on the second day and I guess he was
the second or third and we had a good 30 mins chat about Ofbiz and our
personal how-about as this was the first time we met each other.

I haven't worked closely with him but have good respect for him based on
his contribution to Ofbiz and his commitment towards Ofbiz and the
community.

Adrian will be missed a lot by Ofbiz Community.

May God give all the strength to his family and loved ones during this
tough time. Adrian Rest in Peace.


On Tue, Jan 5, 2016 at 4:39 PM, Sharan Foga  wrote:

>
> I can't believe it -  This is really, really sad news and I will miss
> Adrian a lot.
>
> We never met but we have had a few Skype calls together and I could feel
> that OFBiz was amazingly important to him. We collaborated on the update of
> the Technical documentation and the potential framework rewrite.
>
> I approached him about doing a talk in Austin last year and he was so keen
> and positive to do something that could help promote the project. I also I
> remember that he laughed a lot when I told him that some people saw him as
> the 'Gatekeeper of the Framework' because he was so thorough in his reviews!
>
> It's taking some time to for it sink in and I still can't believe he wont
> be around anymore. He was a great asset to the project and will be sorely
> missed.
>
> Rest in peace - Adrian.
>
> Thanks
> Sharan
>
> Le 05/01/2016 09:04, Pierre Smits a écrit :
>
>> Hi all,
>>
>> With sadness in my heart I inform you that on January 1st Adrian Crum
>> passed away peacefully. Adrian was hospitalised in December of last year
>> due to suffering from a double pneumonia. He died while being kept
>> sedated.
>>
>> I wish his loved ones, relatives and friends strength in these difficult
>> times.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>>
>