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