Some questions on plugin system
Locked
12
12
Re: Some questions on plugin system
 
Administrator
|
That would be perfect.
The link below could help (thanks to Ron) if we could verify/complete the specialpurpose interdependencies. I think there are none but not totally sure about that, we know about OFBIZ-6110 "Move as much as possible demo data from ecommerce to product or order components" but it's not interdependencies. https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies Jacques Le 01/12/2016 à 10:35, Taher Alkhateeb a écrit : > 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 <[hidden email]> > 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 < >>> [hidden email] >>> >>>> 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 < >>>>> [hidden email] >>>>> >>>>>> 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 < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit : >>>>>>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux < >>>>>>>> [hidden email]> 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 >>>>>>> >>>>>>> >>>>>>> |
Re: Some questions on plugin system
|
In reply to this post by taher
On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb <[hidden email]
> wrote: > [...] > So my suggestion to move forward in the plugin system is to: > - Rename /specialpurpose to /plugins > +1 > - remove /plugins/component-load.xml > +1 > - 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 > +1 Thank you Taher, this looks great to me. Jacopo |
Re: Some questions on plugin system
|
Administrator
|
In reply to this post by Jacques Le Roux
BTW I feel like repeating myself over and over :D, did not remember just stumbled upon it http://markmail.org/message/vax77ozzenxtw2ns
Le 01/12/2016 à 10:56, Jacques Le Roux a écrit : > That would be perfect. > > The link below could help (thanks to Ron) if we could verify/complete the specialpurpose interdependencies. I think there are none but not totally > sure about that, we know about OFBIZ-6110 "Move as much as possible demo data from ecommerce to product or order components" but it's not > interdependencies. > > https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies > > Jacques > > > Le 01/12/2016 à 10:35, Taher Alkhateeb a écrit : >> 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 <[hidden email]> >> 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 < >>>> [hidden email] >>>> >>>>> 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 < >>>>>> [hidden email] >>>>>> >>>>>>> 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 < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit : >>>>>>>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux < >>>>>>>>> [hidden email]> 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 >>>>>>>> >>>>>>>> >>>>>>>> > > |
Re: Some questions on plugin system
|
|
In reply to this post by Jacopo Cappellato-5
For what it is worth: the component-load.xml file solely exists to
facilitate how demo data is loaded. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato < [hidden email]> wrote: > On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < > [hidden email] > > wrote: > > > [...] > > So my suggestion to move forward in the plugin system is to: > > - Rename /specialpurpose to /plugins > > > > +1 > > > > - remove /plugins/component-load.xml > > > > +1 > > > > - 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 > > > > +1 > > Thank you Taher, this looks great to me. > > Jacopo > |
Re: Some questions on plugin system
|
|
Taher, all,
If we all are in favour to remove the component-load .xml everywhere, and leave component dependencies to the list of components in <depend-on component-name="?,??,???"> then we need to revisit the gradle task 'loadDefault' too. Currently that task loads demo data by default (and that requires a specific load order). The same also applies to the function(s) related to XML Data Import Readers. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Dec 1, 2016 at 11:14 AM, Pierre Smits <[hidden email]> wrote: > For what it is worth: the component-load.xml file solely exists to > facilitate how demo data is loaded. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato <jacopo.cappellato@ > hotwaxsystems.com> wrote: > >> On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < >> [hidden email] >> > wrote: >> >> > [...] >> > So my suggestion to move forward in the plugin system is to: >> > - Rename /specialpurpose to /plugins >> > >> >> +1 >> >> >> > - remove /plugins/component-load.xml >> > >> >> +1 >> >> >> > - 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 >> > >> >> +1 >> >> Thank you Taher, this looks great to me. >> >> Jacopo >> > > |
|
Hi Pierre,
What is the load order in /specialpurpose, what depends on what? Also what should we revisit about loadDefault and load readers? Taher Alkhateeb On Thu, Dec 1, 2016 at 1:31 PM, Pierre Smits <[hidden email]> wrote: > Taher, all, > > If we all are in favour to remove the component-load .xml everywhere, and > leave component dependencies to the list of components in <depend-on > component-name="?,??,???"> then we need to revisit the gradle task > 'loadDefault' too. Currently that task loads demo data by default (and that > requires a specific load order). The same also applies to the function(s) > related to XML Data Import Readers. > > Best regards, > > > > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Dec 1, 2016 at 11:14 AM, Pierre Smits <[hidden email]> > wrote: > > > For what it is worth: the component-load.xml file solely exists to > > facilitate how demo data is loaded. > > > > Best regards, > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato <jacopo.cappellato@ > > hotwaxsystems.com> wrote: > > > >> On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < > >> [hidden email] > >> > wrote: > >> > >> > [...] > >> > So my suggestion to move forward in the plugin system is to: > >> > - Rename /specialpurpose to /plugins > >> > > >> > >> +1 > >> > >> > >> > - remove /plugins/component-load.xml > >> > > >> > >> +1 > >> > >> > >> > - 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 > >> > > >> > >> +1 > >> > >> Thank you Taher, this looks great to me. > >> > >> Jacopo > >> > > > > > |
Re: Some questions on plugin system
|
|
Taher,
For insights about what the load order in the special purpose folder is, see the component-load.xml file in that folder. For insights on where the dependencies exists, please visit the wiki page Jacques mentioned earlier and search the various open issues in JIRA about moving demo data from special purpose to application components (there is a huge dependency on demo data in the ecommerce component for e.g. test purposes. The loadDefault task loads demo data by default, which requires the specific load-order. The same applies to loading demo data through the XML Import Data Readers in the DevOps component. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Dec 1, 2016 at 11:39 AM, Taher Alkhateeb <[hidden email] > wrote: > Hi Pierre, > > What is the load order in /specialpurpose, what depends on what? Also what > should we revisit about loadDefault and load readers? > > Taher Alkhateeb > > On Thu, Dec 1, 2016 at 1:31 PM, Pierre Smits <[hidden email]> > wrote: > > > Taher, all, > > > > If we all are in favour to remove the component-load .xml everywhere, and > > leave component dependencies to the list of components in <depend-on > > component-name="?,??,???"> then we need to revisit the gradle task > > 'loadDefault' too. Currently that task loads demo data by default (and > that > > requires a specific load order). The same also applies to the function(s) > > related to XML Data Import Readers. > > > > Best regards, > > > > > > > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Thu, Dec 1, 2016 at 11:14 AM, Pierre Smits <[hidden email]> > > wrote: > > > > > For what it is worth: the component-load.xml file solely exists to > > > facilitate how demo data is loaded. > > > > > > Best regards, > > > > > > Pierre Smits > > > > > > ORRTIZ.COM <http://www.orrtiz.com> > > > OFBiz based solutions & services > > > > > > OFBiz Extensions Marketplace > > > http://oem.ofbizci.net/oci-2/ > > > > > > On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato <jacopo.cappellato@ > > > hotwaxsystems.com> wrote: > > > > > >> On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < > > >> [hidden email] > > >> > wrote: > > >> > > >> > [...] > > >> > So my suggestion to move forward in the plugin system is to: > > >> > - Rename /specialpurpose to /plugins > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - remove /plugins/component-load.xml > > >> > > > >> > > >> +1 > > >> > > >> > > >> > - 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 > > >> > > > >> > > >> +1 > > >> > > >> Thank you Taher, this looks great to me. > > >> > > >> Jacopo > > >> > > > > > > > > > |
Re: Some questions on plugin system
|
|
See also https://issues.apache.org/jira/browse/OFBIZ-8229
Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Dec 1, 2016 at 11:56 AM, Pierre Smits <[hidden email]> wrote: > Taher, > > For insights about what the load order in the special purpose folder is, > see the component-load.xml file in that folder. > For insights on where the dependencies exists, please visit the wiki page > Jacques mentioned earlier and search the various open issues in JIRA about > moving demo data from special purpose to application components (there is a > huge dependency on demo data in the ecommerce component for e.g. test > purposes. > > The loadDefault task loads demo data by default, which requires the > specific load-order. The same applies to loading demo data through the XML > Import Data Readers in the DevOps component. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Dec 1, 2016 at 11:39 AM, Taher Alkhateeb < > [hidden email]> wrote: > >> Hi Pierre, >> >> What is the load order in /specialpurpose, what depends on what? Also what >> should we revisit about loadDefault and load readers? >> >> Taher Alkhateeb >> >> On Thu, Dec 1, 2016 at 1:31 PM, Pierre Smits <[hidden email]> >> wrote: >> >> > Taher, all, >> > >> > If we all are in favour to remove the component-load .xml everywhere, >> and >> > leave component dependencies to the list of components in <depend-on >> > component-name="?,??,???"> then we need to revisit the gradle task >> > 'loadDefault' too. Currently that task loads demo data by default (and >> that >> > requires a specific load order). The same also applies to the >> function(s) >> > related to XML Data Import Readers. >> > >> > Best regards, >> > >> > >> > >> > >> > Pierre Smits >> > >> > ORRTIZ.COM <http://www.orrtiz.com> >> > OFBiz based solutions & services >> > >> > OFBiz Extensions Marketplace >> > http://oem.ofbizci.net/oci-2/ >> > >> > On Thu, Dec 1, 2016 at 11:14 AM, Pierre Smits <[hidden email]> >> > wrote: >> > >> > > For what it is worth: the component-load.xml file solely exists to >> > > facilitate how demo data is loaded. >> > > >> > > Best regards, >> > > >> > > Pierre Smits >> > > >> > > ORRTIZ.COM <http://www.orrtiz.com> >> > > OFBiz based solutions & services >> > > >> > > OFBiz Extensions Marketplace >> > > http://oem.ofbizci.net/oci-2/ >> > > >> > > On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato <jacopo.cappellato@ >> > > hotwaxsystems.com> wrote: >> > > >> > >> On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < >> > >> [hidden email] >> > >> > wrote: >> > >> >> > >> > [...] >> > >> > So my suggestion to move forward in the plugin system is to: >> > >> > - Rename /specialpurpose to /plugins >> > >> > >> > >> >> > >> +1 >> > >> >> > >> >> > >> > - remove /plugins/component-load.xml >> > >> > >> > >> >> > >> +1 >> > >> >> > >> >> > >> > - 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 >> > >> > >> > >> >> > >> +1 >> > >> >> > >> Thank you Taher, this looks great to me. >> > >> >> > >> Jacopo >> > >> >> > > >> > > >> > >> > > |
|
|
In reply to this post by Pierre Smits
Okay, so I don't see anything requiring change. Thank you for the input
On Thu, Dec 1, 2016 at 1:56 PM, Pierre Smits <[hidden email]> wrote: > Taher, > > For insights about what the load order in the special purpose folder is, > see the component-load.xml file in that folder. > For insights on where the dependencies exists, please visit the wiki page > Jacques mentioned earlier and search the various open issues in JIRA about > moving demo data from special purpose to application components (there is a > huge dependency on demo data in the ecommerce component for e.g. test > purposes. > > The loadDefault task loads demo data by default, which requires the > specific load-order. The same applies to loading demo data through the XML > Import Data Readers in the DevOps component. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Dec 1, 2016 at 11:39 AM, Taher Alkhateeb < > [hidden email] > > wrote: > > > Hi Pierre, > > > > What is the load order in /specialpurpose, what depends on what? Also > what > > should we revisit about loadDefault and load readers? > > > > Taher Alkhateeb > > > > On Thu, Dec 1, 2016 at 1:31 PM, Pierre Smits <[hidden email]> > > wrote: > > > > > Taher, all, > > > > > > If we all are in favour to remove the component-load .xml everywhere, > and > > > leave component dependencies to the list of components in <depend-on > > > component-name="?,??,???"> then we need to revisit the gradle task > > > 'loadDefault' too. Currently that task loads demo data by default (and > > that > > > requires a specific load order). The same also applies to the > function(s) > > > related to XML Data Import Readers. > > > > > > Best regards, > > > > > > > > > > > > > > > Pierre Smits > > > > > > ORRTIZ.COM <http://www.orrtiz.com> > > > OFBiz based solutions & services > > > > > > OFBiz Extensions Marketplace > > > http://oem.ofbizci.net/oci-2/ > > > > > > On Thu, Dec 1, 2016 at 11:14 AM, Pierre Smits <[hidden email]> > > > wrote: > > > > > > > For what it is worth: the component-load.xml file solely exists to > > > > facilitate how demo data is loaded. > > > > > > > > Best regards, > > > > > > > > Pierre Smits > > > > > > > > ORRTIZ.COM <http://www.orrtiz.com> > > > > OFBiz based solutions & services > > > > > > > > OFBiz Extensions Marketplace > > > > http://oem.ofbizci.net/oci-2/ > > > > > > > > On Thu, Dec 1, 2016 at 11:08 AM, Jacopo Cappellato > <jacopo.cappellato@ > > > > hotwaxsystems.com> wrote: > > > > > > > >> On Thu, Dec 1, 2016 at 10:35 AM, Taher Alkhateeb < > > > >> [hidden email] > > > >> > wrote: > > > >> > > > >> > [...] > > > >> > So my suggestion to move forward in the plugin system is to: > > > >> > - Rename /specialpurpose to /plugins > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - remove /plugins/component-load.xml > > > >> > > > > >> > > > >> +1 > > > >> > > > >> > > > >> > - 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 > > > >> > > > > >> > > > >> +1 > > > >> > > > >> Thank you Taher, this looks great to me. > > > >> > > > >> Jacopo > > > >> > > > > > > > > > > > > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |