Hello Everyone, After doing some refactoring on the core framework, I came to realize that we can make /specialpurpose behave like hot-deploy by simply deleting the component-load.xml. Instead, activating and deactivating the components can happen by going to an ofbiz-component.xml file and setting <ofbiz--component enabled="false" ...> (thank you Jacopo for the tip).
The only benefit of component-load.xml is to specify the order of loading, BUT, i discovered something not yet implemented in ofbiz-component.xml called <depend-on component-name="whatever"/> to specify dependencies between components. If we implement this feature then we don't need the component-load.xml anywhere (this requires cleanup first because we have some circular dependencies). So my suggestion to move forward in the plugin system is to: - Rename /specialpurpose to /plugins - remove /plugins/component-load.xml - Refactor gradle to 1) not load a component if enabled="false" and 2) if a component directory does not have a component-load.xml then load everything Ideas? Taher Alkhateeb On Thu, Nov 24, 2016 at 1:02 AM, Nicolas Malin <[email protected]> wrote: > Hello Taher, > > Your svn reorganization look fine, I just a doubt if in the future we > arrive to separate the framework and application. And an other on all git > connected on the current svn structure. > > After I'm in favor to continue the way, first on deploy plugin only by > source and when we define the rules around plugin release and best pratice > for official, we can thinking about an official repo or use an existing > > Nicolas > > > Le 28/09/2016 à 10:30, Taher Alkhateeb a écrit : > >> Hello Everyone, >> >> Trying to move forward with our plugin system in OFBiz, I suggest the >> following changes: >> >> - Create a task called "pullPluginSource" which pulls an official Apache >> OFBiz plugin from a source repository (version control). This task serves >> specifically for developing plugins on Trunk or upgrading them on >> releases. >> - Create a new SVN repository for plugins with a structure similar to the >> following: >> - ofbiz-core/trunk (what we have) >> - ofbiz-core/branches/RELX.Y.Z >> - ofbiz-plugins/trunk/birt >> - ofbiz-plugins/trunk/cmssite >> - ofbiz-plugins/trunk/ecommerce >> - ofbiz-plugins/branches/RELX.Y.Z >> - and so on >> - Rename /specialpurpose to /plugins >> - Move all components in specialpurpose to the new SVN tree as per the >> above mentioned directory structure >> >> Under these changes, the workflow for plugins would be as follows: >> >> - Using OFBiz release with a specific version of a plugin: ./gradlew >> pullPlugin -PdependencyId='org.apache.ofbiz.plugin:myplugin:0.1.5' >> - Using OFBiz trunk with a specific version of a plugin: ./gradlew >> pullPlugin -PdependencyId='org.apache.ofbiz.plugin:myplugin:0.1.5' >> - Using OFBiz trunk with latest source code of a plugin: ./gradlew >> pullPluginSource -PpluginId=myplugin for the latest code >> >> I think this completes the development cycle for plugins and allows for >> official OFBiz plugins to reside in a separate code base and to have both >> release, and source versions residing in trunk. >> >> What do you think? Ideas, Suggestions? >> >> Cheers, >> >> Taher Alkhateeb >> >> On Thu, Sep 15, 2016 at 2:22 PM, Taher Alkhateeb < >> [email protected] >> >>> wrote: >>> Thank you Jacopo, work is committed in r1760917 which mostly involves >>> changes to the master build.gradle and README.md to describe the plugin >>> system. >>> >>> On Thu, Sep 15, 2016 at 9:05 AM, Jacopo Cappellato <jacopo.cappellato@ >>> hotwaxsystems.com> wrote: >>> >>> Hi Taher, >>>> >>>> this is a follow up to the reviews and comments posted by me and others >>>> to >>>> the work you have contributed in OFBIZ-7972. >>>> Considering the feedback so far, and the minimal risk of side effects >>>> that >>>> your contribution may cause, I am asking you to commit your code to >>>> trunk: >>>> in this way it will be easier for all contributors to start playing with >>>> this new plugin api. >>>> >>>> Jacopo >>>> >>>> >>>> On Tue, Sep 13, 2016 at 7:20 PM, Taher Alkhateeb < >>>> [email protected] >>>> >>>>> wrote: >>>>> Hello Folks, >>>>> >>>>> After quite a bit of work, I have a first working PoC for the plugin >>>>> >>>> system >>>> >>>>> with the following highlights: >>>>> >>>>> - Plugins are OFBiz components that reside in /specialpurpose >>>>> (hopefully >>>>> renamed to /plugins later) >>>>> - Plugins can be published to maven repositories and retrieved from >>>>> >>>> maven >>>> >>>>> repositories >>>>> - Plugins can have dependencies on other plugins >>>>> - I created a minimal set of tasks that do the essentials: >>>>> createPlugin, >>>>> installPlugin, uninstallPlugin, pullPlugin (install from maven repo) >>>>> and >>>>> publishPlugin (publish it to maven repo on localhost) >>>>> - I provided documentation in README.md >>>>> >>>>> I appreciate your help in feedback, ideas, testing and sharing whatever >>>>> >>>> is >>>> >>>>> on your mind. >>>>> >>>>> You will find the patch in https://issues.apache.org/ >>>>> jira/browse/OFBIZ-7972 >>>>> >>>>> Cheers, >>>>> >>>>> Taher Alkhateeb >>>>> >>>>> >>>>> >>>>> On Fri, Sep 9, 2016 at 12:55 PM, Jacques Le Roux < >>>>> [email protected]> wrote: >>>>> >>>>> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit : >>>>>> >>>>>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>> So it would be easier for us (OFBiz team) and contributors to >>>>>>>> >>>>>>> deliver >>>> >>>>> (at >>>>> >>>>>> least free) plugins [...] >>>>>>>> >>>>>>>> The terms "us", "OFBiz team" and the distinction with "contributors" >>>>>>> >>>>>> don't >>>>> >>>>>> make much sense to me and can cause confusion: there is just one >>>>>>> >>>>>> "OFBiz >>>> >>>>> community" in which everyone can contribute with ideas, work, code... >>>>>>> >>>>>> and >>>>> >>>>>> plugins. >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> Yes you are right, and actually, as Taher outlined, the >>>>>>> >>>>>> components/plugins provided by OFBiz OOTB would not fit in the >>>>>> >>>>> possible >>>> >>>>> use >>>>> >>>>>> of JitPack anyway. >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>> >
