Plugins could be used for separating the modules, this will be more
interesting in Grails 2.0 when the plugin framework will use OSGi -
http://jira.codehaus.org/browse/GRAILS-2221
Rather than bring ofbiz to grails, you may find it would be easier to
bring grails to ofbiz, for example it should be relatively trivial to
sit a grails app on top of ofbiz (i.e. as a war file), and use grails to
access the current ofbiz services.
Note that you can already use groovy for writing ofbiz services.
Eventually, when GSP gets separated from grails, this could be used in
ofbiz instead of ftl - http://jira.codehaus.org/browse/GRAILS-5657
Note that OpenTaps 1.5 (ofbiz derivative) uses hibernate for the
persistence layer instead of the home grown ofbiz ORM. It would be nice
to see an option like that in ofbiz!
Miles Huang wrote:
May be the Grails plugin mechanism is a good solution for the modularity
problem. If we separate the OFBIZ components into stand-alone Grails
plugins, each component is just like separated Grails applications, which
can be maintained in their own source directory structure. And during
development period, the Grails framework can provide sophisticated
mechanisms to resolve the OFBIZ module dependency. At runtime, the dependent
components are just deployed alongside with the referencing components in
the same web application, remote service call is not required.
I'm not familiar with OSGi, so I can't say much about it. But if we need to
support dynamical deploy/undeploy componets and multi-version module, the
OSGi promise sounds attractive. Through a quick glance at the presentation
from spring source ( OSGi 4.2 the Blueprint Service RI provider ), my
understanding is the OSGi will take the responsibility to manage the web
application dynamic module, while the web app framework such as Grails will
take the responsibility to construct the dynamic module implementation
framework. Does this mean OSGI and Grails technology can be integrated
without overlaps and conflicts?
