Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Pierre Smits]

Hi Jacques, all,

Currently, we can't avoid having duplicates in test data when we load such
data just before the execution a test-suite/test-case. We should not
concern ourselves to much with this. After all it is just data for test,
and reloading a few duplicates should not be regarded as a major issue.

However, if the community is adamantly set on removing such duplicates,
then it should work on having test-data being loaded before any and all
test-suites/test-cases gets executed. IMO this involves moving test-data
from within the testdef folder (like in the order component) to the data
folder of the component and having a separate loadTestData task.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Suraj,
>
> Can't we avoid the duplicated data?
>
> Jacques
>
> Le 27/04/2019 à 15:17, Suraj Khurana a écrit :
> > Hello team,
> >
> > I have checked and found that there is a data dependency of
> > workEffortId=9000 in the test case which is available in
> plugins/projectmgr
> > component.
> >
> > This was the main reason testIntegration was failing without having
> plugins
> > component. I will take care of it and add respective dependent data on
> > order test data file.
> >
> > I think its making sense now and we don't need to revert now.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> >
> >
> >
> >
> >
> >
> > On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana 
> > wrote:
> >
> >> Sure Jacques,
> >>
> >> I am into it today and if got nothing I will remove OrderTests.groovy
> >>
> >> --
> >> Best Regards,
> >> Suraj Khurana
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Hi Suraj,
> >>>
> >>> I think that, as suggested by Mathieu, in the meantime it's better to
> >>> remove “OrderTests.groovy”
> >>>
> >>> Because it could hide other issues else reported by Buildbot which is
> our
> >>> last safeguard
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>> Le 25/04/2019 à 10:52, Pierre Smits a écrit :
>  Hi Mathieu,
> 
>  Is there a way to move this forward?
> 
>  Best regards,
> 
>  Pierre Smits
> 
>  *Apache Trafodion , Vice President*
>  *Apache Directory , PMC Member*
>  Apache Incubator , committer
>  *Apache OFBiz , contributor (without
> >>> privileges)
>  since 2008*
>  Apache Steve , committer
> 
> 
>  On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits 
> >>> wrote:
> > Maybe we should move the load aspects regarding tests out of the test
> > suite invocations altogether.
> > The gradlew tasks states:
> >
> > task testIntegration(group: ofbizServer) {
> >
> > dependsOn 'ofbiz --test'
> >
> > description 'Run OFBiz integration tests; You must run loadAll before
> > running this task'
> >
> > }
> >
> >
> > IMO, loading test data could be part of the loadAll task.
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> >>> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >
> > On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin <
> >>> mathieu.lir...@nereide.fr>
> > wrote:
> >
> >> Pierre Smits  writes:
> >>
> >>> I believe there are a few more where testing individual test-suites
> >> and/or
> >>> test-cases are dependent on data loaded in other test-suites and/or
> >> other
> >>> test-cases.
> >> I have the same experience.  Moreover another source of fragility is
> >> that tests depend on other tests within a single OFBiz “test-case”,
> >> meaning one test can depend on the data produced by another test.
> >>> This
> >> is acceptable for a “simple-method-test” because the order of
> >>> execution
> >> is sequential and managed by OFBiz, but this is problematic for
> JUnit
> >> tests (Groovy, Java) because the order while being deterministic
> >>> depends
> >> on the arbitrary order imposed by the JVM.
> >>
> >> For example I know for a fact that “QuoteTests.groovy” is suffering
> >>> from
> >> that issue.
> >>
> >>> While 

Re: Confusing implementation of the quickAdd feature of e-commerce

[Vivek Bisen]

Thanks  @Rishi Solanki   for your
recommendation,
As recommended, I have changed the template and added the patch for the
same.

Please have a look and let me know in case of any concerns.
Thanks in advance !!


On Sat, Apr 27, 2019 at 10:37 PM Rishi Solanki 
wrote:

> Dear Pawan,
> In general template should be change. So that we can reuse the data
> preparation logic. In case quick add is not working due to some
> parameters/context missing then we can think of separate groovy for
> ecommerce.
> But first we try to reuse the base component logics in plugin component.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>
>
> On Sat, Apr 27, 2019 at 8:44 PM Pawan Verma  >
> wrote:
>
> > Hello Devs,
> >
> > While looking into OFBIZ-10978, I found the implementation of the
> quickAdd
> > feature of e-commerce confusing.
> >
> > What I found under the quickadd screen of ecommerce/CatalogScreens.xml is
> > that the UI and data preparation layers are in no sync to each other.
> > The QuickAdd.groovy file has the correct implementation of the QuickAdd
> > feature (as per the ordermgr component) and the FTL has been designed as
> > per e-commerce.
> >
> > I think we need to take a decision here about the quickadd screen.
> >
> > Should we make this feature same as quickadd feature of ordermgr?
> > OR
> > Should we write separate data preparation logic for quickadd feature of
> > e-commerce?
> >
> > Suggestions are most welcome. Thanks!
> >
> > --
> > Kind Regards,
> > *Pawan Verma* | Technical Consultant
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P. 452010
> > Linkedin: *Pawan Verma *
> >
>


-- 
Thanks & Regards
*Vivek Singh Bisen* | Enterprise Software Engineer
Hotwax Systems Pvt. Ltd.
Cell Phone: +91-9650184929

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Jacques Le Roux]

Yes you are right Pierre, it's not a worry when it's only for test, missed that

Jacques

Le 28/04/2019 à 09:52, Pierre Smits a écrit :

Hi Jacques, all,

Currently, we can't avoid having duplicates in test data when we load such
data just before the execution a test-suite/test-case. We should not
concern ourselves to much with this. After all it is just data for test,
and reloading a few duplicates should not be regarded as a major issue.

However, if the community is adamantly set on removing such duplicates,
then it should work on having test-data being loaded before any and all
test-suites/test-cases gets executed. IMO this involves moving test-data
from within the testdef folder (like in the order component) to the data
folder of the component and having a separate loadTestData task.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Suraj,

Can't we avoid the duplicated data?

Jacques

Le 27/04/2019 à 15:17, Suraj Khurana a écrit :

Hello team,

I have checked and found that there is a data dependency of
workEffortId=9000 in the test case which is available in

plugins/projectmgr

component.

This was the main reason testIntegration was failing without having

plugins

component. I will take care of it and add respective dependent data on
order test data file.

I think its making sense now and we don't need to revert now.

--
Best Regards,
Suraj Khurana






On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana 
wrote:


Sure Jacques,

I am into it today and if got nothing I will remove OrderTests.groovy

--
Best Regards,
Suraj Khurana







On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

I think that, as suggested by Mathieu, in the meantime it's better to
remove “OrderTests.groovy”

Because it could hide other issues else reported by Buildbot which is

our

last safeguard

Thanks

Jacques

Le 25/04/2019 à 10:52, Pierre Smits a écrit :

Hi Mathieu,

Is there a way to move this forward?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits 

wrote:

Maybe we should move the load aspects regarding tests out of the test
suite invocations altogether.
The gradlew tasks states:

task testIntegration(group: ofbizServer) {

dependsOn 'ofbiz --test'

description 'Run OFBiz integration tests; You must run loadAll before
running this task'

}


IMO, loading test data could be part of the loadAll task.


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin <

mathieu.lir...@nereide.fr>

wrote:


Pierre Smits  writes:


I believe there are a few more where testing individual test-suites

and/or

test-cases are dependent on data loaded in other test-suites and/or

other

test-cases.

I have the same experience.  Moreover another source of fragility is
that tests depend on other tests within a single OFBiz “test-case”,
meaning one test can depend on the data produced by another test.

This

is acceptable for a “simple-method-test” because the order of

execution

is sequential and managed by OFBiz, but this is problematic for

JUnit

tests (Groovy, Java) because the order while being deterministic

depends

on the arbitrary order imposed by the JVM.

For example I know for a fact that “QuoteTests.groovy” is suffering

from

that issue.


While I don't hear/read about failing testIntegration (except where

code in

the base is faulty, not when test-suites/cases are faulty), I see

following

failures in test executions in OFBiz against jdk11:


  1. Execution failed for task ':ofbiz --test component=webapp

--test

  suitename=webapptests'.
  2. Execution failed for task ':ofbiz --test

component=accounting

--test

  suitename=invoicetest'.
  3. Execution failed for task ':ofbiz --test component=order

--test

  suitename=ordertests'.
  4. Execution failed for task ':ofbiz --test component=product

--test

  suitename=producttests'.

Do we have these te

Re: Manufacturer Support In Promotion Engine

[Swapnil Shah]

It should be nice add. However i would have more more liked to have it
supported in the form of Price Rule as well (if it isn't already). Many a
times the mark down or mark up by manufacturers are not necessarily meant
to be propogated as adjustment on top of the existing price to the end
customer. Instead it should be directly billed at the revised prices from
the manufacturer.

Thanks,
Swapnil

On Sat, Apr 27, 2019 at 6:32 PM Rishi Solanki 
wrote:

> Devs,
> Currently promotion engine support all the discount based on party,
> category, party role, party classification, shipping etc.. And promotion
> engine based on the condition decide that the promotion will apply for
> customer purchase over the cart or cart item depending upon the action.
>
> I would like to propose to add support in promotion engine, so that , we
> can add promotion against manufacturing party and should apply to all the
> products manufactured by that party.
>
> For example;
> M1, M2 are two manufacturers.
> M1P1 and M1P2 are products manufactured by M1.
> M2P1 and M2P2 are products manufactured by M2.
>
> Now M1 gives 10% discount on all products M1, and if customer purchase all
> products with quantity ONE.
>
> Assuming all items price is $100. Then CartTotal will be $400 and discount
> amount will be $20. As discount is on M1 products only.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Pierre Smits]

Hi Jacques,

What are you suggesting? More duplicates? Or having all test data loaded
before any test starts?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Apr 28, 2019 at 2:29 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Yes you are right Pierre, it's not a worry when it's only for test, missed
> that
>
> Jacques
>
> Le 28/04/2019 à 09:52, Pierre Smits a écrit :
> > Hi Jacques, all,
> >
> > Currently, we can't avoid having duplicates in test data when we load
> such
> > data just before the execution a test-suite/test-case. We should not
> > concern ourselves to much with this. After all it is just data for test,
> > and reloading a few duplicates should not be regarded as a major issue.
> >
> > However, if the community is adamantly set on removing such duplicates,
> > then it should work on having test-data being loaded before any and all
> > test-suites/test-cases gets executed. IMO this involves moving test-data
> > from within the testdef folder (like in the order component) to the data
> > folder of the component and having a separate loadTestData task.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >
> > On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Thanks Suraj,
> >>
> >> Can't we avoid the duplicated data?
> >>
> >> Jacques
> >>
> >> Le 27/04/2019 à 15:17, Suraj Khurana a écrit :
> >>> Hello team,
> >>>
> >>> I have checked and found that there is a data dependency of
> >>> workEffortId=9000 in the test case which is available in
> >> plugins/projectmgr
> >>> component.
> >>>
> >>> This was the main reason testIntegration was failing without having
> >> plugins
> >>> component. I will take care of it and add respective dependent data on
> >>> order test data file.
> >>>
> >>> I think its making sense now and we don't need to revert now.
> >>>
> >>> --
> >>> Best Regards,
> >>> Suraj Khurana
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana <
> suraj.khur...@hotwax.co>
> >>> wrote:
> >>>
>  Sure Jacques,
> 
>  I am into it today and if got nothing I will remove OrderTests.groovy
> 
>  --
>  Best Regards,
>  Suraj Khurana
> 
> 
> 
> 
> 
> 
> 
>  On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
>  jacques.le.r...@les7arts.com> wrote:
> 
> > Hi Suraj,
> >
> > I think that, as suggested by Mathieu, in the meantime it's better to
> > remove “OrderTests.groovy”
> >
> > Because it could hide other issues else reported by Buildbot which is
> >> our
> > last safeguard
> >
> > Thanks
> >
> > Jacques
> >
> > Le 25/04/2019 à 10:52, Pierre Smits a écrit :
> >> Hi Mathieu,
> >>
> >> Is there a way to move this forward?
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *Apache Trafodion , Vice President*
> >> *Apache Directory , PMC Member*
> >> Apache Incubator , committer
> >> *Apache OFBiz , contributor (without
> > privileges)
> >> since 2008*
> >> Apache Steve , committer
> >>
> >>
> >> On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits <
> pierresm...@apache.org>
> > wrote:
> >>> Maybe we should move the load aspects regarding tests out of the
> test
> >>> suite invocations altogether.
> >>> The gradlew tasks states:
> >>>
> >>> task testIntegration(group: ofbizServer) {
> >>>
> >>> dependsOn 'ofbiz --test'
> >>>
> >>> description 'Run OFBiz integration tests; You must run loadAll
> before
> >>> running this task'
> >>>
> >>> }
> >>>
> >>>
> >>> IMO, loading test data could be part of the loadAll task.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion , Vice President*
> >>> *Apache Directory , PMC Member*
> >>> Apache Incubator , committer
> >>> *Apache OFBiz , contributor (without
> > privileges)
> >>> since 2008*
> >>> Apache Steve 

Re: Manufacturer Support In Promotion Engine

[Pierre Smits]

I would consider to talk about supplier promotions, because it can also
involve wholesale suppliers.

I am inclined to agree with the latest posting by Swapnil.

Whether a supplier promotion is passed to customers is a commercial (
decision, and may be subject to the agreement between the internal party
and the supplier. But they are always intended to drive sales (from the
supplier to the customer, meaning purchases from the internal party to the
supplier).

When the supplier promotion involves an internal runner (a product that
sells well), then the supplier promotion is often not passed down to the
customer.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Apr 28, 2019 at 2:43 PM Swapnil Shah 
wrote:

> It should be nice add. However i would have more more liked to have it
> supported in the form of Price Rule as well (if it isn't already). Many a
> times the mark down or mark up by manufacturers are not necessarily meant
> to be propogated as adjustment on top of the existing price to the end
> customer. Instead it should be directly billed at the revised prices from
> the manufacturer.
>
> Thanks,
> Swapnil
>
> On Sat, Apr 27, 2019 at 6:32 PM Rishi Solanki 
> wrote:
>
> > Devs,
> > Currently promotion engine support all the discount based on party,
> > category, party role, party classification, shipping etc.. And promotion
> > engine based on the condition decide that the promotion will apply for
> > customer purchase over the cart or cart item depending upon the action.
> >
> > I would like to propose to add support in promotion engine, so that , we
> > can add promotion against manufacturing party and should apply to all the
> > products manufactured by that party.
> >
> > For example;
> > M1, M2 are two manufacturers.
> > M1P1 and M1P2 are products manufactured by M1.
> > M2P1 and M2P2 are products manufactured by M2.
> >
> > Now M1 gives 10% discount on all products M1, and if customer purchase
> all
> > products with quantity ONE.
> >
> > Assuming all items price is $100. Then CartTotal will be $400 and
> discount
> > amount will be $20. As discount is on M1 products only.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > 
> > Direct: +91-9893287847
> >
>

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Jacques Le Roux]

Actually I rarely use integration tests independently. Most of the time I 
simply use a batch file which does:

C:\projectsASF\ofbiz>type test.bat
gup cleanAll eclipse loadAll testIntegration
C:\projectsASF\ofbiz>type gup.bat
svn up
cd plugins
svn up
cd ..
gradlew  %*
C:\projectsASF\ofbiz>

In other words to test I barely do the same than the Buildbot script does. It's the only way to be sure of what your are doing. That's pragmatic and 
it works, though it's slow.


So in theory I prefer "having all test data loaded before any test starts"

But that's not contradictory to have data duplicates when you want to run a 
test or a suite alone.

Obviously if you want to be pragmatic (ie often meaning fast) you maybe need 
duplicates.

Not sure what we achieve with this discussion :D

Jacques

Le 28/04/2019 à 15:14, Pierre Smits a écrit :

Hi Jacques,

What are you suggesting? More duplicates? Or having all test data loaded
before any test starts?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Apr 28, 2019 at 2:29 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Yes you are right Pierre, it's not a worry when it's only for test, missed
that

Jacques

Le 28/04/2019 à 09:52, Pierre Smits a écrit :

Hi Jacques, all,

Currently, we can't avoid having duplicates in test data when we load

such

data just before the execution a test-suite/test-case. We should not
concern ourselves to much with this. After all it is just data for test,
and reloading a few duplicates should not be regarded as a major issue.

However, if the community is adamantly set on removing such duplicates,
then it should work on having test-data being loaded before any and all
test-suites/test-cases gets executed. IMO this involves moving test-data
from within the testdef folder (like in the order component) to the data
folder of the component and having a separate loadTestData task.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Suraj,

Can't we avoid the duplicated data?

Jacques

Le 27/04/2019 à 15:17, Suraj Khurana a écrit :

Hello team,

I have checked and found that there is a data dependency of
workEffortId=9000 in the test case which is available in

plugins/projectmgr

component.

This was the main reason testIntegration was failing without having

plugins

component. I will take care of it and add respective dependent data on
order test data file.

I think its making sense now and we don't need to revert now.

--
Best Regards,
Suraj Khurana






On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana <

suraj.khur...@hotwax.co>

wrote:


Sure Jacques,

I am into it today and if got nothing I will remove OrderTests.groovy

--
Best Regards,
Suraj Khurana







On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

I think that, as suggested by Mathieu, in the meantime it's better to
remove “OrderTests.groovy”

Because it could hide other issues else reported by Buildbot which is

our

last safeguard

Thanks

Jacques

Le 25/04/2019 à 10:52, Pierre Smits a écrit :

Hi Mathieu,

Is there a way to move this forward?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits <

pierresm...@apache.org>

wrote:

Maybe we should move the load aspects regarding tests out of the

test

suite invocations altogether.
The gradlew tasks states:

task testIntegration(group: ofbizServer) {

dependsOn 'ofbiz --test'

description 'Run OFBiz integration tests; You must run loadAll

before

running this task'

}


IMO, loading test data could be part of the loadAll task.


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 1:56 PM Math

Re: buildbot failure in on ofbizBranch16

[Swapnil M Mane]

Hi team,
All the tests are passed on my local.
The commit 1858322 [1] should not be responsible for buildbot failure.

[1]
https://github.com/apache/ofbiz/commit/e29cf094893c1abb160f5ebac2d09f62d2290ef9


- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Sun, Apr 28, 2019 at 7:25 PM  wrote:

> The Buildbot has detected a new failure on builder ofbizBranch16 while
> building . Full details are available at:
> https://ci.apache.org/builders/ofbizBranch16/builds/191
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'onOfbizR16Commit'
> triggered this build
> Build Source Stamp: [branch ofbiz/branches/release16.11] 1858322
> Blamelist: swapnilmmane
>
> BUILD FAILED: failed shell_2
>
> Sincerely,
>  -The Buildbot
>
>
>
>