We have done many discussions in the past about publishing OFBiz as deployable JAR and then the plugin mechanism would work as you suggested and you won't need the build system anymore. I remember joining our friend Adrian Crum before he passed away in an attempt to do that but which did not bear fruit.
So, I am in agreement in theory with the concept, but I think realistically this makes the whole "plugin" thing a secondary topic, and the main topic is how to rewrite the core OFBiz framework as an independent JAR with perhaps a single comprehensive webapp, and then make the components deployable (possibly even at runtime) by having this truly pluggable architecture. If you look at the commit history when gradle was introduced, you will notice that in the past there was a little top-level jar created by the start component and then every component would hold its own jars and sources which are then compiled and linked through the old build system (ant) and included through the custom class loader. So it was a mix between ant + class loader to get things going but was still suffering from being one big monolithic thing. So IMHO, perhaps a good approach would have the following preliminary work even before starting to worry about the plugin architecture: - Remove tomcat as an integral container and instead make the web server independent of the framework and vice versa - Delete the entire "container" architecture altogether and just keep thing running in the core - Make everything as a single webapp by default with possible opt-in other webapps - Customize the classloader to allow extending the classpath and loading other components. - Finally, the component concept itself should be redesigned such that every component _is_ an outputted jar file. One thing though, I think the concept of the subproject in gradle would help, not hurt moving towards that goal. It's just that currently, the implementation is not ideal and requires improvements. I don't think ditching the entire subproject functionality is very useful though. Needless to say, this is probably a _lot_ of work. But a good direction to have perhaps. On Thu, Aug 22, 2019 at 11:53 AM Mathieu Lirzin <[email protected]> wrote: > > Hello, > > The plugin mechanism has various issues that make distributing and > extending OFBiz inconvenient and complex. Here are some examples of the > problems I identified: > > 1. Binary distribution of OFBiz needs to include both the Jar and the > ‘ofbiz.home’ directory which make deployment more complex > > 2. Gradle multi-project feature is overly complex (try to understand > “build.gradle”...) and proves to be limited and brittle in practice > (ex. adding an extra Gradle plugin in a subproject can easily break > the build with obscure errors) > > 3. The plugin mechanism is hardly coupled with Gradle which breaks its > API regularly. This means that plugins cannot choose their build > system (Maven, Leinigen, SBT) and cannot expect their plugins to work > with various version of OFBiz reliably. > > 4. There is no flexibility to install plugins outside of the ‘plugins’ > directory of $OFBIZ_HOME. > > 5. Plugins and Framework bytecode is distributed in the same JAR when we > would want instead to independently compile and distribute them. > > > Here is a *big* change that I am considering for OFBiz to fixes those > issues by leveraging the Java platform which already provides everything > that we need to fix those issues: > > - Distributing OFBiz in a Jar with its XML files inside to fix #1 would > allow developpers to extend the framework without compiling it which > removes the hard dependency on Gradle which fixes #2 and #3 and make > the build process snappier. > > - the classpath can be used to compose an arbitrary list of plugins > from various location which fixes #4. > > - The ServiceLoader class [1] is a standard and stable extensibility > mechanism based on JAR metadata which can be used to scan the > available OFBiz components available across multiple JARs that can > replace Gradle complex component bundling to fix #5. > > The biggest challenge with this solution is that we need to do a huge > work of adapting OFBiz to to use location independant resources [3] when > loading XML and GroovyScript files. > > However what this effort would would bring is a convenient and decoupled > way to extend OFBiz by simply declaring a dependency to the framework > and dependant reusable plugins from the project plugin build tool like > that: > > // myApplicationProjectPlugin/build.gradle > dependencies { > implementation "org.apache.ofbiz:ofbiz-framework:18.12" > implementation "org.example:reusable-ofbiz-plugin:0.8" > ... > } > > Would people welcome such change? > > Thanks. > > [1] https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html > [2] https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
