Hello Eugen, [...]
> > I have on my mind to elaborate a framework-core an acceptable minimal > > circular dependencies and some other present as three dependency > > > > * core : common - base - start - entity - service - security - webapp > > * entityext : core > > * datafile: core > > * testtools: core > > * catalina: core > > * widget: core > > * webtools: widget, testtools, datafile, catalina > > > > I know this isn't your final objective but can it be an acceptable spot ? > > Thanks. It's a very good place to start. > We might be able to introduce a 'core' gradle project that contains those > and depend on that one in the others. > > I would move out start module. > It seems to be responsible for starting up the app. > I imagine components have an interface (the Container). > All ofbiz plugins/modules implement this so there should not be a dependency > on implementations. > Perhaps this is a good point to start - separating the container and > depending on it in other modules. > > start will start ofbiz and load modules list from xml + look them up on the > classpath. > > WDYT? How would the list above change with a container API module? About dependency between base and start. Today, Start is packaged in `org.apache.ofbiz.base`, it seems to have been designed to be the only alternative for OFBiz server launch (no other implementation possible). Indeed, this component is the one that stock the launch information (portoffset etc.). To make it happen, there have to be defined interfaces from which actual codebase would be one implementation. Is that what you envision, if so this could be a good first example of circular dependency removal. Other example, regarding common component, that contains common elements applicable to any other component like Unit of measure, lookups, emails. For those, the services can be based upon screen to generate the desired results inducing a dependency toward the widget component. Moreover, lots of display information are propagated by Visual theme, (during login, emails, freemarker engine preparation). We might need to integrate all of these into base component using interface OR split into the good/new component OR decide that OFBiz nature is to live with widgets in its core. > > Another helpful thing is to establish the boundaries of each project. > What should each module do and what it should NOT do? * service : contains all soa configuration and engine to manage services * entity : contains all database / entity management * common : contains functional widget, data, services that can be used by all other components * base : contains technical low level code for all OFBiz components * start : launching, stopping OFBiz server instance, managing start configuration * security : as is named, tools to manage user security * webapp : engine to manage exchange between servlet and controller definition * entityext : container that extend the entity engine on some element not vital for OFBiz to run like entity sync, cache distribution, ... * datafile: tools to create/read big data file base on xml definition * testtools: integration test engine * catalina: container for embedded tomcat * widget: screen rendering based on xml definition * webtools: web interface to analyse and manage different OFBiz engines Thanks Eugen, Nicolas and Gil
signature.asc
Description: PGP signature
