Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

Component Sets

There are a small number of component sets current in OFBiz (from lowest-level to highest-level):

  1. framework
  2. applications
  3. plugins

Dependencies between components in these sets must ONLY go up the list. For example components in plugins can depend on components in applications, but components in applications can not depend on components in plugins.

Unable to render Jira issues macro, execution error. addresses those issues.

Components Within Sets

framework

The framework is the underlying data structures and utilities that supply the essential common features used by the base applications and the extended components. These higher level components will have many dependencies on the framework components. There should be no dependencies in the framework on other parts of OFBiz but a few have crept in. They are shown as the gray arrows in the diagram.
There should be a full discussion on the mailing list before any new dependencies are added. Actually, they should be avoided and even an effort to remove the existing one would be welcome. Framework-only distribution is the first step in this direction...

An overview of the components in the framework stack can be found here:

Framework stack

base applications

While components can depend on one another in the base applications set they should follow the established priority of dependencies. In the diagram below you see existing dependencies and the component dependency priority going from the top of the page down (in other words components higher on the page depends on components lower on the page).

Whenever some data structure or feature could go in multiple components or could depend on elements in multiple components, the design should ensure that lower level components don't depend on something in the higher level ones.

The gray arrows in the diagram represent dependencies that violate the rule and are subject of ongoing discussions about how to fix them.

base applications humanres marketing framework accounting party order product workeffort content eCommerce OFBIZ-6110 manufacturing OFBIZ-6110 entity(ext) service webapp common security extended plugins

An overview of the base applications can be found here:

Base Application stack

Plugins

Components within the plugins set should not depend on each other. If there is a need for components in this set to depend on something in another set, that something should be put into the most appropriate component in the applications set and both plugins components can depend on the applications component. We have currently a dependency of the applications components from, at least, the ecommerce component with regards to the demo data, see  Unable to render Jira issues macro, execution error. for details.

An overview of the plugins applications can be found here:

User-defined components that are not part of OFBiz, as plugins to OFBiz. The same guidelines are recommended here as well.

Plugins stack

Other information

The Framework-only distribution page is related and about "features that should be available in the framework-only OFBiz distribution".

  • No labels

3 Comments

  1. This diagram is missing:

    • a dependency of Accounting on Manufacturing,
    • a dependency of Order on Accounting

     

  2. Added Accounting on Manufacturing which seems wrong.

    It seems unnatural to require manufacturing is your organization is a distributor or consultant.

    Why was this required? Seems like a really poor design.

    Order on Accounting was already there.

     

  3. I put in the graph the dependency from accounting to workeffort introduced by r1710178. This is disputed, see http://markmail.org/message/fw2npvwxisvfeqtn. Jacopo's idea of having all data model in a component apart on which all other components would depend is the solution for this kind of problems...