Merging and Deprecating Components for 3.0.0 Release Series

These are changes I’ve been considering for quite some time, but they will be somewhat disruptive.

One general guideline for which components to merge is when working on functionality there are often multiple components involved, but in some cases there are almost always two components involved which shows that the conceptual split is weak and they should maybe be combined.

  1. deprecate and archive moqui-runtime, add all files to moqui-framework; the original idea with the separation is that moqui-runtime is more likely to be customized than moqui-framework; in common usage I’m aware of this has never been the case which means having 2 components instead of 1 is just cumbersome overhead with no value
  2. deprecate and archive PopCommerce, update the web site to mention Marble ERP instead, recommend usage of Marble ERP over PopCommerce; this will include deprecating the not very useful public facing ecommerce example that is part of the PopCommerce component
  3. create a new component that combines mantle-udm and mantle-usl, perhaps called mantle-ba; in theory it might be interesting to use the data model without the service library, but in practical reality they always go together and even conceptually the service library is very important for the data model as the services are effectively a functional interpretation of the data model that clarify what entities and fields mean and are used for

Feedback welcome… for my part I like the idea of #1 a lot, of #2 a litte, and of #3 less but it’s still possibly helpful.

2 Likes

Typically simplicity trends to promote quality then I’d give +1 for less components with no significant value added

I am personally in favor of all 3 on a personal level. However, why do you want to remove the modularity? I believe it is important to make the core into a single package so the 1st is a good idea. Less so about the third.

Hello @jonesde

One of the things I loved when switching projects from OFBiz to moqui is the separation of everything into repositories and then managing things with gradle. I have some projects that are using 10-13 components and I have no problems managing and updating. It’s really quite a nice and refreshing experience.

What I learned is that separating things though sometimes not very necessary makes for better code quality, because you are sort of forced to think of the boundaries between the components and hence come-up with more generic and abstract solutions and have less entanglements. For example, having the freedom to modify the base-component if I need to without touching the framework is still better than touching the framework directly. Also separating UDM from USL means that I know exactly where to go to find things and it leads to less clutter in the file-system.

So I might be wrong, but I just feel the original design is nice and just makes sense. It’s easy to learn, explain and comprehend. I never felt overwhelmed or annoyed by the number of repositories, and in fact, I rather enjoy breaking things down. I have developed at least 15 generic reusable components not to mention project specific components and I can update with my eyes closed thanks to gradle + some infra work.

1 Like

@taher I would love to know how you set up your git to make dealing with modules easier. My only issue currently is that my project has 22 components and switching between branches project-wide is a pain. Intellij helps. Note, I (for no particular reason) am not using “git submodule”.

1 Like

Hello Mohammad,

Well I think there are 2 aspects to this: technical and cultural / discipline based.

On the technical side, I’ve made a recursive-git CLI script that simply walks the repository tree and apply the same git command on every repo.

However what really makes things easy for us is cultural. We strongly believe in continuous integration and one of the tenants of that discipline is to only have one branch and that branch is both development and production. And to be even more aggressive we are always up to the latest commit from the community. We have “one” version only. This of course requires that you change the way you manage your projects and introducing new disciplines on how to handle hiccups and having a CI tool among other practices can help.

1 Like

Sadly I’m totally in the dark about Marble ERP. I better give it a read.

1 Like

The idea with Marble ERP is simple a combination of PopC and HiveMind