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" <[email protected]> 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 < >> [email protected]> 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 >>> >>> >
