Hi Michael, Good points, thank you for sharing your thoughts. So the dependencies in the past were just jars that we put in the code base which we cannot do for release purposes. But even if we can, although you have the advantage of stable versions, you will have the disadvantage of manually fixing dependency hell. If you issue the command "./gradlew dependencies" and observe the size and complexity of the dependency tree, you will see one massive beast. Doing this by hand is something that I really am grateful to avoid by using a modern tool like Gradle.
For example, a component in framework depends on lib-1.2.3 and a component in plugins depends on lib-1.3.1, gradle would bump the dependency to the higher number. But if you bump the dependency to lib-1.3.1 this might in return depend on different / new libraries which would change the dependency graph. How do we resolve this by hand? I would say .. very painfully :) So whether manually or automatically, in either case you will have a changed dependency tree if you have conflicting libraries between plugins and the rest of the system. That's why I suggested a full split between the two projects .. to test both in isolation from each other. Cheers, Taher Alkhateeeb On Mon, Mar 13, 2017 at 11:39 PM, Michael Brohl <[email protected]> wrote: > Hi Taher, > > first of all, thank you very much for your ongoing hard work on this, I > really appreciate it. > > Maybe I'm a little late joining this discussion but I'd like to express > one view point which I think is really important to ensure stable > production settings. It came to my mind as I read about the transitional > dependendies you mentioned in this thread. > > I think we should preserve a stable way to add functionality to OFBiz in > parallel to the more dynamic plugins mechanism. The plugin system is a > great way to enhance OFBiz through external resources. In productive > business systems, you'll need a stable mechanism to add your internal > functionality the "old" way, maybe with fixed library dependencies relying > on specified release versions, without loading it from external > repositories etc.. > > I'm not really sure if this is guaranteed when we remove the hot-deploy > mechanism and solely rely on the plugins mechanism? > > Best regards, > > Michael > > > Am 12.03.17 um 09:38 schrieb Taher Alkhateeb: > > Hello everyone, >> >> Now that nearly all plugin-API is completed in [5] and [6] and after >> having >> various discussions about the plugins system in [1][2][3] and [4], I >> propose the following action points: >> >> - Remove the hot-deploy directory with all references to it. >> - Create two different buildbot scripts for OFBiz, one for standalone >> ofbiz-framework and the other for ofbiz-framework + ofbiz-plugins. The >> second buildbot script would use the pullAllPluginsSource instead of >> svn:external for combining the two repositories. >> >> WDYT? >> >> [1] https://s.apache.org/5Dv8 - separate plugins in new repo >> [2] https://s.apache.org/7Y2w - hot-deploy removal >> [3] https://s.apache.org/CvW3 - svn:external vs gradle >> [4] https://s.apache.org/LF1o - plugin system design >> [5] https://issues.apache.org/jira/browse/OFBIZ-9182 - new svn for >> plugins >> JIRA >> [6] https://issues.apache.org/jira/browse/OFBIZ-7972 - original work on >> plugin system >> >> Cheers, >> >> Taher Alkhateeb >> >> > >
