Re: buildbot failure in on ofbiz-trunk-framework-plugins

[Jacques Le Roux]

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)

[Jacques Le Roux]

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)

[Jacques Le Roux]

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

[Nicolas Malin]

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