Hello Taher, Taher Alkhateeb <[email protected]> writes:
> 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. Thanks for reminding that past effort, > 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. I have used the old ant build in one of our customer project at Néréide and noticed the separation in multiple jars, but I didn't investigate the internals. > 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. Maybe I am overlooking something but this seems like an interesting but different objective to me. :-) > 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. Sure I am maybe throwing the baby with the bathwater. Gradle multi-projet builds are indeed useful to solve the issue of coordinating the local build and development of multiple source repositories. My only critic is that using this Gradle facility should not be a requirement for extending OFBiz. Thanks for you answer. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
