Re: buildbot failure in on ofbiz-trunk-framework-plugins
I think you were were right Taher, Gavin just removed a duplicate declaration of ofbiz-trunk-framework-plugins, see INFRA-15394 Let's see, but I'm confident Jacques Le 13/12/2017 à 16:21, Taher Alkhateeb a écrit : These error messages are becoming excessive and indicating a faulty buildbot implementation. I would like to work on it. Is anyone interested in helping me or has background information that might help? On Wed, Dec 13, 2017 at 5:36 PM, wrote: The Buildbot has detected a new failure on builder ofbiz-trunk-framework-plugins while building . Full details are available at: https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/877 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-framework-commit' triggered this build Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1818020 Blamelist: jleroux BUILD FAILED: failed shell_4 Sincerely, -The Buildbot
Re: Planning for the creation of the new 17.xx branch(es)
BTW I notice that so fat we used ofbiz.16.11 so maybe we could continue to follow this convention and have ofbiz.17.12 and ofbiz.17.12-plugins If nobody is against I'll do so in few days Jacques Le 30/12/2017 à 12:29, Jacques Le Roux a écrit : Hi Deepak, All, It seems to me that $ svn co http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/branches/release17.12 ofbiz-plugins is maybe not the best name we could use. Because when the next branch will be created we will have to rename. So I propose $ svn co http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/branches/release17.12 release17.12-plugins That's it's only a convention and users can use what they want, but better to use a right convention from start ;) What do you think? Jacques Le 28/12/2017 à 19:06, Deepak Dixit a écrit : Added release17.12 in source repositories page at r#1819433. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Thu, Dec 28, 2017 at 11:23 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 28/12/2017 à 18:23, Jacopo Cappellato a écrit : On Thu, Dec 28, 2017 at 5:47 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 28/12/2017 à 13:09, Michael Brohl a écrit : Regarding the website: 1. do we keep the 16.11 listed there as the stable release branch Yes, until we release 17.12 and add 17.12? No, because 17.12 does not exist yet for users, it's only a freezed version of the trunk (if I can say so) But that page is not the download page, in which only official releases are published; the page we are talking about is the ones that lists our source repositories, including the trunk and so we should definitely add to it the new branches. Jacopo Right, and we need to add the plugins... Jacques
Re: Planning for the creation of the new 17.xx branch(es)
Hi Deepak, All, It seems to me that $ svn co http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/branches/release17.12 ofbiz-plugins is maybe not the best name we could use. Because when the next branch will be created we will have to rename. So I propose $ svn co http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/branches/release17.12 release17.12-plugins That's it's only a convention and users can use what they want, but better to use a right convention from start ;) What do you think? Jacques Le 28/12/2017 à 19:06, Deepak Dixit a écrit : Added release17.12 in source repositories page at r#1819433. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Thu, Dec 28, 2017 at 11:23 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 28/12/2017 à 18:23, Jacopo Cappellato a écrit : On Thu, Dec 28, 2017 at 5:47 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 28/12/2017 à 13:09, Michael Brohl a écrit : Regarding the website: 1. do we keep the 16.11 listed there as the stable release branch Yes, until we release 17.12 and add 17.12? No, because 17.12 does not exist yet for users, it's only a freezed version of the trunk (if I can say so) But that page is not the download page, in which only official releases are published; the page we are talking about is the ones that lists our source repositories, including the trunk and so we should definitely add to it the new branches. Jacopo Right, and we need to add the plugins... Jacques
Re: [DISCUSSION] Review ProductPromo action and condition process
Thanks for you return, yes I will try to work on POC this next year. Nicolas Le 12/12/2017 à 12:14, Rishi Solanki a écrit : +1 for the proposal, Nicolas! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Mon, Dec 11, 2017 at 7:20 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Ha I see, you speak about Then yes I understand and I think a POC would be welcome :) Jacques Le 11/12/2017 à 13:08, Jacques Le Roux a écrit : Hi Nicolas, I don't see why you speak about enumeration for ProductPromoCond and ProductPromoAction which are plain entities. Jacques Le 08/12/2017 à 14:14, Nicolas Malin a écrit : Hello, Yesterday during a boring time in the come back home train, I read the ofbiz demo data review that the condition and action method are listed through enumeration like : and liked to the code by java hard code (ProductPromoWorker.java) condition : } else if ("PPIP_PRODUCT_TOTAL".equals(inputParamEnumId)) { // this type of condition allows items involved to be involved in other quantity consuming cond/action, and does pro-rate the price action : } else if ("PROMO_GWP".equals(productPromoActionEnumId)) { ... This isn't really useful to manage and extend it but an idea raise in my mind :) Why not replace the enumeration by a customMethod. We can define a interface service one for action and one for condition, with the related customMethodType. Each hard coded enumeration would be convert to service. Like this we can surcharge the current rules easily and create new one for customer site without modify the core. The main strategy point would be the interface service to pass the good parameters. This is easily to improve on java code, screen and data. What do you thinks ? Do you have an other idea to improve this ? Cheers, Nicolas