[proposal] actions to take with plugins
Locked
 
|
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 |
Re: [proposal] actions to take with plugins
|
I suggest to move theme components from ofbiz-framework to ofbiz-plugins
(or another repo). Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb <[hidden email] > wrote: > 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 > |
Re: [proposal] actions to take with plugins
Administrator
|
In reply to this post by taher
Hi Taher,
First congratulations, it's a great achievement you did with your work on Gradle and the trunk split. Well planned, done and documented. I wish we could always do the same work quality! Even if of course, as always, we crossed some pitfalls on our path. Rest inline... Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : > 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. +1 > - 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? I agree. After some tests (all seem OK so far, tests currently running here), I will remove the ofbiz-framework-buildbot branch and replace the ofbiz-framework-buildbot Buildbot build by ofbiz-framework + ofbiz-plugins and will change the same for the trunk demo. I'll also remove the Buildbot build I created for the ofbiz-plugins branch (no tests, was only a build) and add one for ofbiz-framework alone as you suggest. > [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 > Again Kudos for the all excellent work! Jacques |
Re: [proposal] actions to take with plugins
|
Administrator
|
In reply to this post by Pierre Smits
Hi Pierre,
The question we need to answer here is "Can we consider themes as plugins" At the moment I don't think so, because at least one is necessary and we can't really agree on which one it should be (though Flat Grey seems the most complete) So I'd wait for Julien and Nicolas effort to create a basic theme on which all others would rely. Then indeed it would be a good idea IMO but would need more work than just putting them in plugins because themes don't use the same mechanism than plugins to be "plugged". Jacques Le 12/03/2017 à 10:22, Pierre Smits a écrit : > I suggest to move theme components from ofbiz-framework to ofbiz-plugins > (or another repo). > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb <[hidden email] >> wrote: >> 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 >> |
Re: [proposal] actions to take with plugins
|
Administrator
|
In reply to this post by Jacques Le Roux
Hi Taher,
Inline following the "Plugins packages?" thread. Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : > > Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : > >> - 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? > I agree. After some tests (all seem OK so far, tests currently running here), I will remove the ofbiz-framework-buildbot branch and replace the > ofbiz-framework-buildbot Buildbot build by ofbiz-framework + ofbiz-plugins and will change the same for the trunk demo. > I'll also remove the Buildbot build I created for the ofbiz-plugins branch (no tests, was only a build) and add one for ofbiz-framework alone as you > suggest. From our last discussion in Hipchat, you want to put a hand in the Buildbot scripts. Great, I felt alone so far :) Now I was wondering, why would we need an ofbiz-framework Buildbot script? We can achieve all with the ofbiz-framework + ofbiz-plugins script. What I would do after the 1st svn step: 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource loadDefault testIntegration . No need for "build", it's included in loadDefault. You have to put all the arguments as strings separated with commas. 2) Continue to create a ofbiz-trunk-framework-.zip archive 3) Create a ofbiz-trunk-plugins-.zip archive reusing the ofbiz-trunk-plugins builder source The rest should not change So it would slightly be less pull on resources, and especially we can remove the ofbiz-trunk-plugins builder and all related, even the ofbiz-trunk-plugins-rat builder. because all would be included in ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) So it would be finally simpler. WDYT? Jacques |
|
|
Hi Jacques,
It seems you might be missing the implications of a full split between the framework and plugins including with buildbot. So I will try to explain why I think it is extremely important to completely separate the build process into two unrelated, non-synchronized setups: - First, the dependencies of ofbiz-framework without ofbiz-plugins is different from the dependencies of ofbiz-framework + ofbiz-plugins. So testing needs to happen in both scenarios because you might face library version bugs. - Next, to ensure real separation between the two projects, you must test each in isolation. For example, right now, ofbiz-framework alone does not pass tests. Why? because it depends on data found in the ecommerce component. Separating the builds would force us to fix this issue - Let's say a design change was made in the framework that had regressions or implications on the plugins, the committer should not worry about getting both builds right. First, the commiter should commit and make sure the framework works correctly and as expected. Then in a later stage same committer or someone could help fix the plugins. I believe that without a full and strong separation between the two products, we gain absolutely no value and actually get more work and headache instead. Regards, Taher Alkhateeb On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < [hidden email]> wrote: > Hi Taher, > > Inline following the "Plugins packages?" thread. > > > Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : > >> >> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >> >> - 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? >>> >> I agree. After some tests (all seem OK so far, tests currently running >> here), I will remove the ofbiz-framework-buildbot branch and replace the >> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + ofbiz-plugins >> and will change the same for the trunk demo. >> I'll also remove the Buildbot build I created for the ofbiz-plugins >> branch (no tests, was only a build) and add one for ofbiz-framework alone >> as you suggest. >> > > From our last discussion in Hipchat, you want to put a hand in the > Buildbot scripts. Great, I felt alone so far :) > > Now I was wondering, why would we need an ofbiz-framework Buildbot script? > We can achieve all with the ofbiz-framework + ofbiz-plugins script. What I > would do after the 1st svn step: > 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource > loadDefault testIntegration . No need for "build", it's included in > loadDefault. You have to put all the arguments as strings separated with > commas. > 2) Continue to create a ofbiz-trunk-framework-.zip archive > 3) Create a ofbiz-trunk-plugins-.zip archive reusing the > ofbiz-trunk-plugins builder source > The rest should not change > So it would slightly be less pull on resources, and especially we can > remove the ofbiz-trunk-plugins builder and all related, even the > ofbiz-trunk-plugins-rat builder. because all would be included in > ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) > So it would be finally simpler. > > WDYT? > > Jacques > |
Re: [proposal] actions to take with plugins
|
Administrator
|
Hi Taher,
Inline... Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : > Hi Jacques, > > It seems you might be missing the implications of a full split between the > framework and plugins including with buildbot. So I will try to explain why > I think it is extremely important to completely separate the build process > into two unrelated, non-synchronized setups: > > - First, the dependencies of ofbiz-framework without ofbiz-plugins is > different from the dependencies of ofbiz-framework + ofbiz-plugins. So > testing needs to happen in both scenarios because you might face library > version bugs. build alone. I don't clearly see what the ofbiz-framework build brings in. Because the plugins dependencies are specified in plugins. So, if a plugin changes its dependencies, nothing should change in the main build, so no implications for ofbiz-framework build, right? It also means that, each time we would make a change on the framework, both builds will run which is not negligible, and more work to maintain. > - Next, to ensure real separation between the two projects, So far, it's not 2 projects but 2 products ;) > you must test each in isolation. For example, right now, ofbiz-framework alone does not > pass tests. Why? because it depends on data found in the ecommerce > component. Separating the builds would force us to fix this issue We must previously fix the already known issues and get a stable situation. Among known issues, at least https://issues.apache.org/jira/browse/OFBIZ-9243 https://issues.apache.org/jira/browse/OFBIZ-6976 https://issues.apache.org/jira/browse/OFBIZ-9241 I see no points uselessly running a failing build for months (I don't expect above to be fixed in few weeks) Later if we find good reasons the ofbiz-framework build might be activated. I'm not yet convinced so far, but I'm sure you have good reasons I still don't get. > - Let's say a design change was made in the framework that had regressions > or implications on the plugins, the committer should not worry about > getting both builds right. First, the commiter should commit and make sure > the framework works correctly and as expected. Then in a later stage same > committer or someone could help fix the plugins. I differ here, I see a separation of concerns I don't like. It seems to me that if a committer, committing something on the framework, breaks a plugins s/he is also responsible of fixing the plugins issue. This is something I already addressed some times ago in another message http://markmail.org/message/lbz6o4i5vshlglkp <<I believe committers need now to agree about checking out all plugins and maintaining them as we did before. This must be documented in our policies.>> Nobody said anything about this important point of our policies! > I believe that without a full and strong separation between the two > products, we gain absolutely no value and actually get more work and > headache instead. This is to be seen. Actually it's not only a technical issue but also a political one, on how we see the separation of the products. Anyway, let's keep infra resources unaffected as long as at least the above issues are not fixed. Jacques > > Regards, > > Taher Alkhateeb > > On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Hi Taher, >> >> Inline following the "Plugins packages?" thread. >> >> >> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >> >>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>> >>> - 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? >>>> >>> I agree. After some tests (all seem OK so far, tests currently running >>> here), I will remove the ofbiz-framework-buildbot branch and replace the >>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + ofbiz-plugins >>> and will change the same for the trunk demo. >>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>> branch (no tests, was only a build) and add one for ofbiz-framework alone >>> as you suggest. >>> >> From our last discussion in Hipchat, you want to put a hand in the >> Buildbot scripts. Great, I felt alone so far :) >> >> Now I was wondering, why would we need an ofbiz-framework Buildbot script? >> We can achieve all with the ofbiz-framework + ofbiz-plugins script. What I >> would do after the 1st svn step: >> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >> loadDefault testIntegration . No need for "build", it's included in >> loadDefault. You have to put all the arguments as strings separated with >> commas. >> 2) Continue to create a ofbiz-trunk-framework-.zip archive >> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >> ofbiz-trunk-plugins builder source >> The rest should not change >> So it would slightly be less pull on resources, and especially we can >> remove the ofbiz-trunk-plugins builder and all related, even the >> ofbiz-trunk-plugins-rat builder. because all would be included in >> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >> So it would be finally simpler. >> >> WDYT? >> >> Jacques >> |
|
|
So I'm not going to reply to everything because we both made our points. My
reply is mostly for dependencies. Ofbiz + plugins is not just a difference of the plugins dependencies. No you actually get different versions of libraries (up or down) and sometimes even different libraries altogether from transitive dependencies. So the answer to your question is definitely no, they are not the same and the dependency graph changes if you remove plugins. Secondly, I don't think it would take weeks, not even hours to move the data from ecommerce to the framework. Just move a few XML files and that's it. In fact I don't mind moving the data myself while building two build scripts for the two products. On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> wrote: > Hi Taher, > > Inline... > > Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> It seems you might be missing the implications of a full split between the >> framework and plugins including with buildbot. So I will try to explain >> why >> I think it is extremely important to completely separate the build process >> into two unrelated, non-synchronized setups: >> >> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >> testing needs to happen in both scenarios because you might face library >> version bugs. >> > It should only happens when running the ofbiz-framework + ofbiz-plugins > build. I see no reasons we would get library version bugs with > ofbiz-framework build alone. > I don't clearly see what the ofbiz-framework build brings in. Because the > plugins dependencies are specified in plugins. > So, if a plugin changes its dependencies, nothing should change in the > main build, so no implications for ofbiz-framework build, right? > It also means that, each time we would make a change on the framework, > both builds will run which is not negligible, and more work to maintain. > >> - Next, to ensure real separation between the two projects, >> > So far, it's not 2 projects but 2 products ;) > >> you must test each in isolation. For example, right now, ofbiz-framework >> alone does not >> pass tests. Why? because it depends on data found in the ecommerce >> component. Separating the builds would force us to fix this issue >> > We must previously fix the already known issues and get a stable > situation. Among known issues, at least > https://issues.apache.org/jira/browse/OFBIZ-9243 > https://issues.apache.org/jira/browse/OFBIZ-6976 > https://issues.apache.org/jira/browse/OFBIZ-9241 > I see no points uselessly running a failing build for months (I don't > expect above to be fixed in few weeks) > Later if we find good reasons the ofbiz-framework build might be > activated. I'm not yet convinced so far, but I'm sure you have good reasons > I still don't get. > >> - Let's say a design change was made in the framework that had regressions >> or implications on the plugins, the committer should not worry about >> getting both builds right. First, the commiter should commit and make sure >> the framework works correctly and as expected. Then in a later stage same >> committer or someone could help fix the plugins. >> > I differ here, I see a separation of concerns I don't like. It seems to me > that if a committer, committing something on the framework, breaks a > plugins s/he is also responsible of fixing the plugins issue. > This is something I already addressed some times ago in another message > http://markmail.org/message/lbz6o4i5vshlglkp > <<I believe committers need now to agree about checking out all plugins > and maintaining them as we did before. This must be documented in our > policies.>> > Nobody said anything about this important point of our policies! > >> I believe that without a full and strong separation between the two >> products, we gain absolutely no value and actually get more work and >> headache instead. >> > This is to be seen. Actually it's not only a technical issue but also a > political one, on how we see the separation of the products. > Anyway, let's keep infra resources unaffected as long as at least the > above issues are not fixed. > > Jacques > >> >> Regards, >> >> Taher Alkhateeb >> >> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> Hi Taher, >>> >>> Inline following the "Plugins packages?" thread. >>> >>> >>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>> >>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>> >>>> - 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? >>>>> >>>>> I agree. After some tests (all seem OK so far, tests currently running >>>> here), I will remove the ofbiz-framework-buildbot branch and replace the >>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>> ofbiz-plugins >>>> and will change the same for the trunk demo. >>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>> alone >>>> as you suggest. >>>> >>>> From our last discussion in Hipchat, you want to put a hand in the >>> Buildbot scripts. Great, I felt alone so far :) >>> >>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>> script? >>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. What >>> I >>> would do after the 1st svn step: >>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>> loadDefault testIntegration . No need for "build", it's included in >>> loadDefault. You have to put all the arguments as strings separated with >>> commas. >>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>> ofbiz-trunk-plugins builder source >>> The rest should not change >>> So it would slightly be less pull on resources, and especially we can >>> remove the ofbiz-trunk-plugins builder and all related, even the >>> ofbiz-trunk-plugins-rat builder. because all would be included in >>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>> So it would be finally simpler. >>> >>> WDYT? >>> >>> Jacques >>> >>> > |
Re: [proposal] actions to take with plugins
|
Administrator
|
I did not say it the same dependencies graph. Anyway I'll also not continue on this, please do as you like and we will see then.
If you look at the links (and subtasks) I provided, it's a "bit" more than moving few XML files, notably OFBIZ-9241. And with these links we have no completeness guarantee. The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies could help on where to move seed and demo data from ecommerce. Looking forward :) Jacques Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit : > So I'm not going to reply to everything because we both made our points. My > reply is mostly for dependencies. Ofbiz + plugins is not just a difference > of the plugins dependencies. No you actually get different versions of > libraries (up or down) and sometimes even different libraries altogether > from transitive dependencies. So the answer to your question is definitely > no, they are not the same and the dependency graph changes if you remove > plugins. > > Secondly, I don't think it would take weeks, not even hours to move the > data from ecommerce to the framework. Just move a few XML files and that's > it. In fact I don't mind moving the data myself while building two build > scripts for the two products. > > On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> > wrote: > >> Hi Taher, >> >> Inline... >> >> Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : >> >>> Hi Jacques, >>> >>> It seems you might be missing the implications of a full split between the >>> framework and plugins including with buildbot. So I will try to explain >>> why >>> I think it is extremely important to completely separate the build process >>> into two unrelated, non-synchronized setups: >>> >>> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >>> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >>> testing needs to happen in both scenarios because you might face library >>> version bugs. >>> >> It should only happens when running the ofbiz-framework + ofbiz-plugins >> build. I see no reasons we would get library version bugs with >> ofbiz-framework build alone. >> I don't clearly see what the ofbiz-framework build brings in. Because the >> plugins dependencies are specified in plugins. >> So, if a plugin changes its dependencies, nothing should change in the >> main build, so no implications for ofbiz-framework build, right? >> It also means that, each time we would make a change on the framework, >> both builds will run which is not negligible, and more work to maintain. >> >>> - Next, to ensure real separation between the two projects, >>> >> So far, it's not 2 projects but 2 products ;) >> >>> you must test each in isolation. For example, right now, ofbiz-framework >>> alone does not >>> pass tests. Why? because it depends on data found in the ecommerce >>> component. Separating the builds would force us to fix this issue >>> >> We must previously fix the already known issues and get a stable >> situation. Among known issues, at least >> https://issues.apache.org/jira/browse/OFBIZ-9243 >> https://issues.apache.org/jira/browse/OFBIZ-6976 >> https://issues.apache.org/jira/browse/OFBIZ-9241 >> I see no points uselessly running a failing build for months (I don't >> expect above to be fixed in few weeks) >> Later if we find good reasons the ofbiz-framework build might be >> activated. I'm not yet convinced so far, but I'm sure you have good reasons >> I still don't get. >> >>> - Let's say a design change was made in the framework that had regressions >>> or implications on the plugins, the committer should not worry about >>> getting both builds right. First, the commiter should commit and make sure >>> the framework works correctly and as expected. Then in a later stage same >>> committer or someone could help fix the plugins. >>> >> I differ here, I see a separation of concerns I don't like. It seems to me >> that if a committer, committing something on the framework, breaks a >> plugins s/he is also responsible of fixing the plugins issue. >> This is something I already addressed some times ago in another message >> http://markmail.org/message/lbz6o4i5vshlglkp >> <<I believe committers need now to agree about checking out all plugins >> and maintaining them as we did before. This must be documented in our >> policies.>> >> Nobody said anything about this important point of our policies! >> >>> I believe that without a full and strong separation between the two >>> products, we gain absolutely no value and actually get more work and >>> headache instead. >>> >> This is to be seen. Actually it's not only a technical issue but also a >> political one, on how we see the separation of the products. >> Anyway, let's keep infra resources unaffected as long as at least the >> above issues are not fixed. >> >> Jacques >> >>> Regards, >>> >>> Taher Alkhateeb >>> >>> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Hi Taher, >>>> Inline following the "Plugins packages?" thread. >>>> >>>> >>>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>>> >>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>>> - 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? >>>>>> >>>>>> I agree. After some tests (all seem OK so far, tests currently running >>>>> here), I will remove the ofbiz-framework-buildbot branch and replace the >>>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>>> ofbiz-plugins >>>>> and will change the same for the trunk demo. >>>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>>> alone >>>>> as you suggest. >>>>> >>>>> From our last discussion in Hipchat, you want to put a hand in the >>>> Buildbot scripts. Great, I felt alone so far :) >>>> >>>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>>> script? >>>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. What >>>> I >>>> would do after the 1st svn step: >>>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>>> loadDefault testIntegration . No need for "build", it's included in >>>> loadDefault. You have to put all the arguments as strings separated with >>>> commas. >>>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>>> ofbiz-trunk-plugins builder source >>>> The rest should not change >>>> So it would slightly be less pull on resources, and especially we can >>>> remove the ofbiz-trunk-plugins builder and all related, even the >>>> ofbiz-trunk-plugins-rat builder. because all would be included in >>>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>>> So it would be finally simpler. >>>> >>>> WDYT? >>>> >>>> Jacques >>>> >>>> |
|
|
Well here is exactly what you said:
"So, if a plugin changes its dependencies, nothing should change in the main build, so no implications for ofbiz-framework build, right?" And the answer is, no, there _are_ implications which I explained in my previous post. Anyway, I leave it for the community to pitch in their opinion before going in any direction with this. There is no point in all of this work if people are not interested in the plugin system anyway. So please everyone, feel free to share your thoughts, we need your guidance in this! On Mon, Mar 13, 2017 at 6:43 PM, Jacques Le Roux < [hidden email]> wrote: > I did not say it the same dependencies graph. Anyway I'll also not > continue on this, please do as you like and we will see then. > > If you look at the links (and subtasks) I provided, it's a "bit" more than > moving few XML files, notably OFBIZ-9241. And with these links we have no > completeness guarantee. > > The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+ > and+Component+Set+Dependencies could help on where to move seed and demo > data from ecommerce. > > Looking forward :) > > Jacques > > > > Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit : > >> So I'm not going to reply to everything because we both made our points. >> My >> reply is mostly for dependencies. Ofbiz + plugins is not just a difference >> of the plugins dependencies. No you actually get different versions of >> libraries (up or down) and sometimes even different libraries altogether >> from transitive dependencies. So the answer to your question is definitely >> no, they are not the same and the dependency graph changes if you remove >> plugins. >> >> Secondly, I don't think it would take weeks, not even hours to move the >> data from ecommerce to the framework. Just move a few XML files and that's >> it. In fact I don't mind moving the data myself while building two build >> scripts for the two products. >> >> On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> >> wrote: >> >> Hi Taher, >>> >>> Inline... >>> >>> Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : >>> >>> Hi Jacques, >>>> >>>> It seems you might be missing the implications of a full split between >>>> the >>>> framework and plugins including with buildbot. So I will try to explain >>>> why >>>> I think it is extremely important to completely separate the build >>>> process >>>> into two unrelated, non-synchronized setups: >>>> >>>> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >>>> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >>>> testing needs to happen in both scenarios because you might face library >>>> version bugs. >>>> >>>> It should only happens when running the ofbiz-framework + ofbiz-plugins >>> build. I see no reasons we would get library version bugs with >>> ofbiz-framework build alone. >>> I don't clearly see what the ofbiz-framework build brings in. Because the >>> plugins dependencies are specified in plugins. >>> So, if a plugin changes its dependencies, nothing should change in the >>> main build, so no implications for ofbiz-framework build, right? >>> It also means that, each time we would make a change on the framework, >>> both builds will run which is not negligible, and more work to maintain. >>> >>> - Next, to ensure real separation between the two projects, >>>> >>>> So far, it's not 2 projects but 2 products ;) >>> >>> you must test each in isolation. For example, right now, ofbiz-framework >>>> alone does not >>>> pass tests. Why? because it depends on data found in the ecommerce >>>> component. Separating the builds would force us to fix this issue >>>> >>>> We must previously fix the already known issues and get a stable >>> situation. Among known issues, at least >>> https://issues.apache.org/jira/browse/OFBIZ-9243 >>> https://issues.apache.org/jira/browse/OFBIZ-6976 >>> https://issues.apache.org/jira/browse/OFBIZ-9241 >>> I see no points uselessly running a failing build for months (I don't >>> expect above to be fixed in few weeks) >>> Later if we find good reasons the ofbiz-framework build might be >>> activated. I'm not yet convinced so far, but I'm sure you have good >>> reasons >>> I still don't get. >>> >>> - Let's say a design change was made in the framework that had >>>> regressions >>>> or implications on the plugins, the committer should not worry about >>>> getting both builds right. First, the commiter should commit and make >>>> sure >>>> the framework works correctly and as expected. Then in a later stage >>>> same >>>> committer or someone could help fix the plugins. >>>> >>>> I differ here, I see a separation of concerns I don't like. It seems to >>> me >>> that if a committer, committing something on the framework, breaks a >>> plugins s/he is also responsible of fixing the plugins issue. >>> This is something I already addressed some times ago in another message >>> http://markmail.org/message/lbz6o4i5vshlglkp >>> <<I believe committers need now to agree about checking out all plugins >>> and maintaining them as we did before. This must be documented in our >>> policies.>> >>> Nobody said anything about this important point of our policies! >>> >>> I believe that without a full and strong separation between the two >>>> products, we gain absolutely no value and actually get more work and >>>> headache instead. >>>> >>>> This is to be seen. Actually it's not only a technical issue but also a >>> political one, on how we see the separation of the products. >>> Anyway, let's keep infra resources unaffected as long as at least the >>> above issues are not fixed. >>> >>> Jacques >>> >>> Regards, >>>> >>>> Taher Alkhateeb >>>> >>>> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> Hi Taher, >>>> >>>>> Inline following the "Plugins packages?" thread. >>>>> >>>>> >>>>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>>>> >>>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>>> >>>>>> - 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? >>>>>>> >>>>>>> I agree. After some tests (all seem OK so far, tests currently >>>>>>> running >>>>>>> >>>>>> here), I will remove the ofbiz-framework-buildbot branch and replace >>>>>> the >>>>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>>>> ofbiz-plugins >>>>>> and will change the same for the trunk demo. >>>>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>>>> alone >>>>>> as you suggest. >>>>>> >>>>>> From our last discussion in Hipchat, you want to put a hand in the >>>>>> >>>>> Buildbot scripts. Great, I felt alone so far :) >>>>> >>>>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>>>> script? >>>>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. >>>>> What >>>>> I >>>>> would do after the 1st svn step: >>>>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>>>> loadDefault testIntegration . No need for "build", it's included in >>>>> loadDefault. You have to put all the arguments as strings separated >>>>> with >>>>> commas. >>>>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>>>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>>>> ofbiz-trunk-plugins builder source >>>>> The rest should not change >>>>> So it would slightly be less pull on resources, and especially we can >>>>> remove the ofbiz-trunk-plugins builder and all related, even the >>>>> ofbiz-trunk-plugins-rat builder. because all would be included in >>>>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>>>> So it would be finally simpler. >>>>> >>>>> WDYT? >>>>> >>>>> Jacques >>>>> >>>>> >>>>> > |
Re: [proposal] actions to take with plugins
|
|
In reply to this post by taher
+1
Regards, James Yong
|
Re: [proposal] actions to take with plugins
|
|
In reply to this post by taher
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 > |
smime.p7s (5K)
Re: [proposal] actions to take with plugins
|
|
In reply to this post by Jacques Le Roux
I agree that themes are different from plugins, providing
cross-sectional functionality and I think that we should treat them differently. Regards, Michael Am 12.03.17 um 11:58 schrieb Jacques Le Roux: > Hi Pierre, > > The question we need to answer here is "Can we consider themes as > plugins" > At the moment I don't think so, because at least one is necessary and > we can't really agree on which one it should be (though Flat Grey > seems the most complete) > So I'd wait for Julien and Nicolas effort to create a basic theme on > which all others would rely. > > Then indeed it would be a good idea IMO but would need more work than > just putting them in plugins because themes don't use the same > mechanism than plugins to be "plugged". > > Jacques > > Le 12/03/2017 à 10:22, Pierre Smits a écrit : >> I suggest to move theme components from ofbiz-framework to ofbiz-plugins >> (or another repo). >> >> Best regards, >> >> Pierre Smits >> >> ORRTIZ.COM <http://www.orrtiz.com> >> OFBiz based solutions & services >> >> OFBiz Extensions Marketplace >> http://oem.ofbizci.net/oci-2/ >> >> On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb >> <[hidden email] >>> wrote: >>> 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 >>> > |
|
|
In reply to this post by Michael Brohl-3
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 <[hidden email]> 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 >> >> > > |
Re: [proposal] actions to take with plugins
|
Administrator
|
In reply to this post by taher
Hi Taher,
I got your point and you are right. Now I think all the community should focus on decoupling the plugins from the framework. In the meantime I still think it's no point running the ofbiz-framework build on Buildbot Jacques Le 13/03/2017 à 16:51, Taher Alkhateeb a écrit : > Well here is exactly what you said: > > "So, if a plugin changes its dependencies, nothing should change in the > main build, so no implications for ofbiz-framework build, right?" > > And the answer is, no, there _are_ implications which I explained in my > previous post. > > Anyway, I leave it for the community to pitch in their opinion before going > in any direction with this. There is no point in all of this work if people > are not interested in the plugin system anyway. So please everyone, feel > free to share your thoughts, we need your guidance in this! > > On Mon, Mar 13, 2017 at 6:43 PM, Jacques Le Roux < > [hidden email]> wrote: > >> I did not say it the same dependencies graph. Anyway I'll also not >> continue on this, please do as you like and we will see then. >> >> If you look at the links (and subtasks) I provided, it's a "bit" more than >> moving few XML files, notably OFBIZ-9241. And with these links we have no >> completeness guarantee. >> >> The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+ >> and+Component+Set+Dependencies could help on where to move seed and demo >> data from ecommerce. >> >> Looking forward :) >> >> Jacques >> >> >> >> Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit : >> >>> So I'm not going to reply to everything because we both made our points. >>> My >>> reply is mostly for dependencies. Ofbiz + plugins is not just a difference >>> of the plugins dependencies. No you actually get different versions of >>> libraries (up or down) and sometimes even different libraries altogether >>> from transitive dependencies. So the answer to your question is definitely >>> no, they are not the same and the dependency graph changes if you remove >>> plugins. >>> >>> Secondly, I don't think it would take weeks, not even hours to move the >>> data from ecommerce to the framework. Just move a few XML files and that's >>> it. In fact I don't mind moving the data myself while building two build >>> scripts for the two products. >>> >>> On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> >>> wrote: >>> >>> Hi Taher, >>>> Inline... >>>> >>>> Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : >>>> >>>> Hi Jacques, >>>>> It seems you might be missing the implications of a full split between >>>>> the >>>>> framework and plugins including with buildbot. So I will try to explain >>>>> why >>>>> I think it is extremely important to completely separate the build >>>>> process >>>>> into two unrelated, non-synchronized setups: >>>>> >>>>> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >>>>> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >>>>> testing needs to happen in both scenarios because you might face library >>>>> version bugs. >>>>> >>>>> It should only happens when running the ofbiz-framework + ofbiz-plugins >>>> build. I see no reasons we would get library version bugs with >>>> ofbiz-framework build alone. >>>> I don't clearly see what the ofbiz-framework build brings in. Because the >>>> plugins dependencies are specified in plugins. >>>> So, if a plugin changes its dependencies, nothing should change in the >>>> main build, so no implications for ofbiz-framework build, right? >>>> It also means that, each time we would make a change on the framework, >>>> both builds will run which is not negligible, and more work to maintain. >>>> >>>> - Next, to ensure real separation between the two projects, >>>>> So far, it's not 2 projects but 2 products ;) >>>> you must test each in isolation. For example, right now, ofbiz-framework >>>>> alone does not >>>>> pass tests. Why? because it depends on data found in the ecommerce >>>>> component. Separating the builds would force us to fix this issue >>>>> >>>>> We must previously fix the already known issues and get a stable >>>> situation. Among known issues, at least >>>> https://issues.apache.org/jira/browse/OFBIZ-9243 >>>> https://issues.apache.org/jira/browse/OFBIZ-6976 >>>> https://issues.apache.org/jira/browse/OFBIZ-9241 >>>> I see no points uselessly running a failing build for months (I don't >>>> expect above to be fixed in few weeks) >>>> Later if we find good reasons the ofbiz-framework build might be >>>> activated. I'm not yet convinced so far, but I'm sure you have good >>>> reasons >>>> I still don't get. >>>> >>>> - Let's say a design change was made in the framework that had >>>>> regressions >>>>> or implications on the plugins, the committer should not worry about >>>>> getting both builds right. First, the commiter should commit and make >>>>> sure >>>>> the framework works correctly and as expected. Then in a later stage >>>>> same >>>>> committer or someone could help fix the plugins. >>>>> >>>>> I differ here, I see a separation of concerns I don't like. It seems to >>>> me >>>> that if a committer, committing something on the framework, breaks a >>>> plugins s/he is also responsible of fixing the plugins issue. >>>> This is something I already addressed some times ago in another message >>>> http://markmail.org/message/lbz6o4i5vshlglkp >>>> <<I believe committers need now to agree about checking out all plugins >>>> and maintaining them as we did before. This must be documented in our >>>> policies.>> >>>> Nobody said anything about this important point of our policies! >>>> >>>> I believe that without a full and strong separation between the two >>>>> products, we gain absolutely no value and actually get more work and >>>>> headache instead. >>>>> >>>>> This is to be seen. Actually it's not only a technical issue but also a >>>> political one, on how we see the separation of the products. >>>> Anyway, let's keep infra resources unaffected as long as at least the >>>> above issues are not fixed. >>>> >>>> Jacques >>>> >>>> Regards, >>>>> Taher Alkhateeb >>>>> >>>>> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> Hi Taher, >>>>> >>>>>> Inline following the "Plugins packages?" thread. >>>>>> >>>>>> >>>>>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>>>>> >>>>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>>>> >>>>>>> - 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? >>>>>>>> >>>>>>>> I agree. After some tests (all seem OK so far, tests currently >>>>>>>> running >>>>>>>> >>>>>>> here), I will remove the ofbiz-framework-buildbot branch and replace >>>>>>> the >>>>>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>>>>> ofbiz-plugins >>>>>>> and will change the same for the trunk demo. >>>>>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>>>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>>>>> alone >>>>>>> as you suggest. >>>>>>> >>>>>>> From our last discussion in Hipchat, you want to put a hand in the >>>>>>> >>>>>> Buildbot scripts. Great, I felt alone so far :) >>>>>> >>>>>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>>>>> script? >>>>>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. >>>>>> What >>>>>> I >>>>>> would do after the 1st svn step: >>>>>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>>>>> loadDefault testIntegration . No need for "build", it's included in >>>>>> loadDefault. You have to put all the arguments as strings separated >>>>>> with >>>>>> commas. >>>>>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>>>>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>>>>> ofbiz-trunk-plugins builder source >>>>>> The rest should not change >>>>>> So it would slightly be less pull on resources, and especially we can >>>>>> remove the ofbiz-trunk-plugins builder and all related, even the >>>>>> ofbiz-trunk-plugins-rat builder. because all would be included in >>>>>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>>>>> So it would be finally simpler. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> |
Re: [proposal] actions to take with plugins
|
Administrator
|
OK I have finally done it. We have now 2 new Buildbot builders
ofbiz-trunk-framework-plugins runs the test and that's all ofbiz-trunk-framework runs the build and creates the ofbiz-trunk-framework snapshot ofbiz-trunk-plugins is not new, it only creates the ofbiz-trunk-plugins snapshot The snapshots are visible at https://ci.apache.org/projects/ofbiz/snapshots/. I wonder if we really need snapshots. All tests in all branches passed with success but the R14 and I have no ideas why. Maybe the issue we get in R14 will surface again in other branches. I'll then see why it's OK locally but randomly not on Buildbot Jacques Le 14/03/2017 à 07:07, Jacques Le Roux a écrit : > Hi Taher, > > I got your point and you are right. Now I think all the community should focus on decoupling the plugins from the framework. > > In the meantime I still think it's no point running the ofbiz-framework build on Buildbot > > Jacques > > > Le 13/03/2017 à 16:51, Taher Alkhateeb a écrit : >> Well here is exactly what you said: >> >> "So, if a plugin changes its dependencies, nothing should change in the >> main build, so no implications for ofbiz-framework build, right?" >> >> And the answer is, no, there _are_ implications which I explained in my >> previous post. >> >> Anyway, I leave it for the community to pitch in their opinion before going >> in any direction with this. There is no point in all of this work if people >> are not interested in the plugin system anyway. So please everyone, feel >> free to share your thoughts, we need your guidance in this! >> >> On Mon, Mar 13, 2017 at 6:43 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> I did not say it the same dependencies graph. Anyway I'll also not >>> continue on this, please do as you like and we will see then. >>> >>> If you look at the links (and subtasks) I provided, it's a "bit" more than >>> moving few XML files, notably OFBIZ-9241. And with these links we have no >>> completeness guarantee. >>> >>> The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+ >>> and+Component+Set+Dependencies could help on where to move seed and demo >>> data from ecommerce. >>> >>> Looking forward :) >>> >>> Jacques >>> >>> >>> >>> Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit : >>> >>>> So I'm not going to reply to everything because we both made our points. >>>> My >>>> reply is mostly for dependencies. Ofbiz + plugins is not just a difference >>>> of the plugins dependencies. No you actually get different versions of >>>> libraries (up or down) and sometimes even different libraries altogether >>>> from transitive dependencies. So the answer to your question is definitely >>>> no, they are not the same and the dependency graph changes if you remove >>>> plugins. >>>> >>>> Secondly, I don't think it would take weeks, not even hours to move the >>>> data from ecommerce to the framework. Just move a few XML files and that's >>>> it. In fact I don't mind moving the data myself while building two build >>>> scripts for the two products. >>>> >>>> On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> >>>> wrote: >>>> >>>> Hi Taher, >>>>> Inline... >>>>> >>>>> Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : >>>>> >>>>> Hi Jacques, >>>>>> It seems you might be missing the implications of a full split between >>>>>> the >>>>>> framework and plugins including with buildbot. So I will try to explain >>>>>> why >>>>>> I think it is extremely important to completely separate the build >>>>>> process >>>>>> into two unrelated, non-synchronized setups: >>>>>> >>>>>> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >>>>>> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >>>>>> testing needs to happen in both scenarios because you might face library >>>>>> version bugs. >>>>>> >>>>>> It should only happens when running the ofbiz-framework + ofbiz-plugins >>>>> build. I see no reasons we would get library version bugs with >>>>> ofbiz-framework build alone. >>>>> I don't clearly see what the ofbiz-framework build brings in. Because the >>>>> plugins dependencies are specified in plugins. >>>>> So, if a plugin changes its dependencies, nothing should change in the >>>>> main build, so no implications for ofbiz-framework build, right? >>>>> It also means that, each time we would make a change on the framework, >>>>> both builds will run which is not negligible, and more work to maintain. >>>>> >>>>> - Next, to ensure real separation between the two projects, >>>>>> So far, it's not 2 projects but 2 products ;) >>>>> you must test each in isolation. For example, right now, ofbiz-framework >>>>>> alone does not >>>>>> pass tests. Why? because it depends on data found in the ecommerce >>>>>> component. Separating the builds would force us to fix this issue >>>>>> >>>>>> We must previously fix the already known issues and get a stable >>>>> situation. Among known issues, at least >>>>> https://issues.apache.org/jira/browse/OFBIZ-9243 >>>>> https://issues.apache.org/jira/browse/OFBIZ-6976 >>>>> https://issues.apache.org/jira/browse/OFBIZ-9241 >>>>> I see no points uselessly running a failing build for months (I don't >>>>> expect above to be fixed in few weeks) >>>>> Later if we find good reasons the ofbiz-framework build might be >>>>> activated. I'm not yet convinced so far, but I'm sure you have good >>>>> reasons >>>>> I still don't get. >>>>> >>>>> - Let's say a design change was made in the framework that had >>>>>> regressions >>>>>> or implications on the plugins, the committer should not worry about >>>>>> getting both builds right. First, the commiter should commit and make >>>>>> sure >>>>>> the framework works correctly and as expected. Then in a later stage >>>>>> same >>>>>> committer or someone could help fix the plugins. >>>>>> >>>>>> I differ here, I see a separation of concerns I don't like. It seems to >>>>> me >>>>> that if a committer, committing something on the framework, breaks a >>>>> plugins s/he is also responsible of fixing the plugins issue. >>>>> This is something I already addressed some times ago in another message >>>>> http://markmail.org/message/lbz6o4i5vshlglkp >>>>> <<I believe committers need now to agree about checking out all plugins >>>>> and maintaining them as we did before. This must be documented in our >>>>> policies.>> >>>>> Nobody said anything about this important point of our policies! >>>>> >>>>> I believe that without a full and strong separation between the two >>>>>> products, we gain absolutely no value and actually get more work and >>>>>> headache instead. >>>>>> >>>>>> This is to be seen. Actually it's not only a technical issue but also a >>>>> political one, on how we see the separation of the products. >>>>> Anyway, let's keep infra resources unaffected as long as at least the >>>>> above issues are not fixed. >>>>> >>>>> Jacques >>>>> >>>>> Regards, >>>>>> Taher Alkhateeb >>>>>> >>>>>> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> Hi Taher, >>>>>> >>>>>>> Inline following the "Plugins packages?" thread. >>>>>>> >>>>>>> >>>>>>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>>>>> >>>>>>>> - 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? >>>>>>>>> >>>>>>>>> I agree. After some tests (all seem OK so far, tests currently >>>>>>>>> running >>>>>>>>> >>>>>>>> here), I will remove the ofbiz-framework-buildbot branch and replace >>>>>>>> the >>>>>>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>>>>>> ofbiz-plugins >>>>>>>> and will change the same for the trunk demo. >>>>>>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>>>>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>>>>>> alone >>>>>>>> as you suggest. >>>>>>>> >>>>>>>> From our last discussion in Hipchat, you want to put a hand in the >>>>>>>> >>>>>>> Buildbot scripts. Great, I felt alone so far :) >>>>>>> >>>>>>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>>>>>> script? >>>>>>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. >>>>>>> What >>>>>>> I >>>>>>> would do after the 1st svn step: >>>>>>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>>>>>> loadDefault testIntegration . No need for "build", it's included in >>>>>>> loadDefault. You have to put all the arguments as strings separated >>>>>>> with >>>>>>> commas. >>>>>>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>>>>>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>>>>>> ofbiz-trunk-plugins builder source >>>>>>> The rest should not change >>>>>>> So it would slightly be less pull on resources, and especially we can >>>>>>> remove the ofbiz-trunk-plugins builder and all related, even the >>>>>>> ofbiz-trunk-plugins-rat builder. because all would be included in >>>>>>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>>>>>> So it would be finally simpler. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> > > |
Re: [proposal] actions to take with plugins
|
Administrator
|
Le 21/03/2017 à 15:32, Jacques Le Roux a écrit :
> OK I have finally done it. We have now 2 new Buildbot builders > > ofbiz-trunk-framework-plugins runs the test and that's all > > ofbiz-trunk-framework runs the build and creates the ofbiz-trunk-framework snapshot > > ofbiz-trunk-plugins is not new, it only creates the ofbiz-trunk-plugins snapshot > > The snapshots are visible at https://ci.apache.org/projects/ofbiz/snapshots/. I wonder if we really need snapshots. > > All tests in all branches passed with success but the R14 and I have no ideas why. Maybe the issue we get in R14 will surface again in other > branches. I'll then see why it's OK locally but randomly not on Buildbot Finally the same happens with the ofbiz-trunk-framework-plugins. So I'll investigate before I guess asking Infra to have a look in their Buildbot config. Jacques > > Jacques > > > Le 14/03/2017 à 07:07, Jacques Le Roux a écrit : >> Hi Taher, >> >> I got your point and you are right. Now I think all the community should focus on decoupling the plugins from the framework. >> >> In the meantime I still think it's no point running the ofbiz-framework build on Buildbot >> >> Jacques >> >> >> Le 13/03/2017 à 16:51, Taher Alkhateeb a écrit : >>> Well here is exactly what you said: >>> >>> "So, if a plugin changes its dependencies, nothing should change in the >>> main build, so no implications for ofbiz-framework build, right?" >>> >>> And the answer is, no, there _are_ implications which I explained in my >>> previous post. >>> >>> Anyway, I leave it for the community to pitch in their opinion before going >>> in any direction with this. There is no point in all of this work if people >>> are not interested in the plugin system anyway. So please everyone, feel >>> free to share your thoughts, we need your guidance in this! >>> >>> On Mon, Mar 13, 2017 at 6:43 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>>> I did not say it the same dependencies graph. Anyway I'll also not >>>> continue on this, please do as you like and we will see then. >>>> >>>> If you look at the links (and subtasks) I provided, it's a "bit" more than >>>> moving few XML files, notably OFBIZ-9241. And with these links we have no >>>> completeness guarantee. >>>> >>>> The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+ >>>> and+Component+Set+Dependencies could help on where to move seed and demo >>>> data from ecommerce. >>>> >>>> Looking forward :) >>>> >>>> Jacques >>>> >>>> >>>> >>>> Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit : >>>> >>>>> So I'm not going to reply to everything because we both made our points. >>>>> My >>>>> reply is mostly for dependencies. Ofbiz + plugins is not just a difference >>>>> of the plugins dependencies. No you actually get different versions of >>>>> libraries (up or down) and sometimes even different libraries altogether >>>>> from transitive dependencies. So the answer to your question is definitely >>>>> no, they are not the same and the dependency graph changes if you remove >>>>> plugins. >>>>> >>>>> Secondly, I don't think it would take weeks, not even hours to move the >>>>> data from ecommerce to the framework. Just move a few XML files and that's >>>>> it. In fact I don't mind moving the data myself while building two build >>>>> scripts for the two products. >>>>> >>>>> On Mar 13, 2017 4:20 PM, "Jacques Le Roux" <[hidden email]> >>>>> wrote: >>>>> >>>>> Hi Taher, >>>>>> Inline... >>>>>> >>>>>> Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit : >>>>>> >>>>>> Hi Jacques, >>>>>>> It seems you might be missing the implications of a full split between >>>>>>> the >>>>>>> framework and plugins including with buildbot. So I will try to explain >>>>>>> why >>>>>>> I think it is extremely important to completely separate the build >>>>>>> process >>>>>>> into two unrelated, non-synchronized setups: >>>>>>> >>>>>>> - First, the dependencies of ofbiz-framework without ofbiz-plugins is >>>>>>> different from the dependencies of ofbiz-framework + ofbiz-plugins. So >>>>>>> testing needs to happen in both scenarios because you might face library >>>>>>> version bugs. >>>>>>> >>>>>>> It should only happens when running the ofbiz-framework + ofbiz-plugins >>>>>> build. I see no reasons we would get library version bugs with >>>>>> ofbiz-framework build alone. >>>>>> I don't clearly see what the ofbiz-framework build brings in. Because the >>>>>> plugins dependencies are specified in plugins. >>>>>> So, if a plugin changes its dependencies, nothing should change in the >>>>>> main build, so no implications for ofbiz-framework build, right? >>>>>> It also means that, each time we would make a change on the framework, >>>>>> both builds will run which is not negligible, and more work to maintain. >>>>>> >>>>>> - Next, to ensure real separation between the two projects, >>>>>>> So far, it's not 2 projects but 2 products ;) >>>>>> you must test each in isolation. For example, right now, ofbiz-framework >>>>>>> alone does not >>>>>>> pass tests. Why? because it depends on data found in the ecommerce >>>>>>> component. Separating the builds would force us to fix this issue >>>>>>> >>>>>>> We must previously fix the already known issues and get a stable >>>>>> situation. Among known issues, at least >>>>>> https://issues.apache.org/jira/browse/OFBIZ-9243 >>>>>> https://issues.apache.org/jira/browse/OFBIZ-6976 >>>>>> https://issues.apache.org/jira/browse/OFBIZ-9241 >>>>>> I see no points uselessly running a failing build for months (I don't >>>>>> expect above to be fixed in few weeks) >>>>>> Later if we find good reasons the ofbiz-framework build might be >>>>>> activated. I'm not yet convinced so far, but I'm sure you have good >>>>>> reasons >>>>>> I still don't get. >>>>>> >>>>>> - Let's say a design change was made in the framework that had >>>>>>> regressions >>>>>>> or implications on the plugins, the committer should not worry about >>>>>>> getting both builds right. First, the commiter should commit and make >>>>>>> sure >>>>>>> the framework works correctly and as expected. Then in a later stage >>>>>>> same >>>>>>> committer or someone could help fix the plugins. >>>>>>> >>>>>>> I differ here, I see a separation of concerns I don't like. It seems to >>>>>> me >>>>>> that if a committer, committing something on the framework, breaks a >>>>>> plugins s/he is also responsible of fixing the plugins issue. >>>>>> This is something I already addressed some times ago in another message >>>>>> http://markmail.org/message/lbz6o4i5vshlglkp >>>>>> <<I believe committers need now to agree about checking out all plugins >>>>>> and maintaining them as we did before. This must be documented in our >>>>>> policies.>> >>>>>> Nobody said anything about this important point of our policies! >>>>>> >>>>>> I believe that without a full and strong separation between the two >>>>>>> products, we gain absolutely no value and actually get more work and >>>>>>> headache instead. >>>>>>> >>>>>>> This is to be seen. Actually it's not only a technical issue but also a >>>>>> political one, on how we see the separation of the products. >>>>>> Anyway, let's keep infra resources unaffected as long as at least the >>>>>> above issues are not fixed. >>>>>> >>>>>> Jacques >>>>>> >>>>>> Regards, >>>>>>> Taher Alkhateeb >>>>>>> >>>>>>> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> Hi Taher, >>>>>>> >>>>>>>> Inline following the "Plugins packages?" thread. >>>>>>>> >>>>>>>> >>>>>>>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit : >>>>>>>> >>>>>>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit : >>>>>>>> >>>>>>>>> - 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? >>>>>>>>>> >>>>>>>>>> I agree. After some tests (all seem OK so far, tests currently >>>>>>>>>> running >>>>>>>>>> >>>>>>>>> here), I will remove the ofbiz-framework-buildbot branch and replace >>>>>>>>> the >>>>>>>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework + >>>>>>>>> ofbiz-plugins >>>>>>>>> and will change the same for the trunk demo. >>>>>>>>> I'll also remove the Buildbot build I created for the ofbiz-plugins >>>>>>>>> branch (no tests, was only a build) and add one for ofbiz-framework >>>>>>>>> alone >>>>>>>>> as you suggest. >>>>>>>>> >>>>>>>>> From our last discussion in Hipchat, you want to put a hand in the >>>>>>>>> >>>>>>>> Buildbot scripts. Great, I felt alone so far :) >>>>>>>> >>>>>>>> Now I was wondering, why would we need an ofbiz-framework Buildbot >>>>>>>> script? >>>>>>>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. >>>>>>>> What >>>>>>>> I >>>>>>>> would do after the 1st svn step: >>>>>>>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource >>>>>>>> loadDefault testIntegration . No need for "build", it's included in >>>>>>>> loadDefault. You have to put all the arguments as strings separated >>>>>>>> with >>>>>>>> commas. >>>>>>>> 2) Continue to create a ofbiz-trunk-framework-.zip archive >>>>>>>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the >>>>>>>> ofbiz-trunk-plugins builder source >>>>>>>> The rest should not change >>>>>>>> So it would slightly be less pull on resources, and especially we can >>>>>>>> remove the ofbiz-trunk-plugins builder and all related, even the >>>>>>>> ofbiz-trunk-plugins-rat builder. because all would be included in >>>>>>>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO) >>>>>>>> So it would be finally simpler. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> >> >> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |