Rename specialpurpose components in Jira

2017-01-30 Thread Jacques Le Roux 

HI,

While doing some Jiras I thought that, after last Taher's work on plugins, one 
day we will need to rename  the specialpurpose components in Jira.

For that I guess we should better wait that all released versions use this 
mechanism, right?

Jacques

Re: Wiki page ASF+Board+Reports

2017-01-30 Thread Jacopo Cappellato 
On Mon, Jan 30, 2017 at 5:46 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> Actually "easier, simpler, KISS way" can also be understood as "lazy".


:-)

Re: Wiki page ASF+Board+Reports

2017-01-30 Thread Jacques Le Roux 

Le 30/01/2017 à 16:02, Jacopo Cappellato a écrit :

On Sat, Jan 28, 2017 at 2:50 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


After Pierre's remark I made a comment and this change:

Note that the last report copied below was "ASF Board Report 2016-06". We
then stopped to copy reports there and you should use thewhimsy link <
https://whimsy.apache.org/board/minutes/OFBiz.html>for newer reports

Easier, simpler, KISS way


Hi Jacques,

I'm fine if you prefer to leave the old reports in the Wiki but I would
like to clarify that Pierre's remark is based on a misunderstanding or lack
of knowledge of the meaning of Board reports and on the procedure used by
the Board to approve: for this reason Pierre's comment shouldn't influence
your decision.

Jacopo


Hi Jacopo,

Actually "easier, simpler, KISS way" can also be understood as "lazy". If somebody think they should be removed (the definitive versions are faster 
found in whimsy), please feel free...


Jacques

Re: Wiki page ASF+Board+Reports

2017-01-30 Thread Jacopo Cappellato 
On Sat, Jan 28, 2017 at 2:50 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> After Pierre's remark I made a comment and this change:
>
> Note that the last report copied below was "ASF Board Report 2016-06". We
> then stopped to copy reports there and you should use thewhimsy link <
> https://whimsy.apache.org/board/minutes/OFBiz.html>for newer reports
>
> Easier, simpler, KISS way


Hi Jacques,

I'm fine if you prefer to leave the old reports in the Wiki but I would
like to clarify that Pierre's remark is based on a misunderstanding or lack
of knowledge of the meaning of Board reports and on the procedure used by
the Board to approve: for this reason Pierre's comment shouldn't influence
your decision.

Jacopo

Re: buildbot failure in on ofbiz-trunk

2017-01-30 Thread Jacques Le Roux 

Thanks Scott,

Inline...


Le 30/01/2017 à 10:03, Scott Gray a écrit :

Try and be patient Jacques, I'm also having trouble understanding what you
are saying.

Here's what I've been able to understand so far:
- Pre-gradle OFBiz tests run fine on buildbot
- Gradle OFBiz fails on buildbot with a complaint that the default ports
are in use
- The test framework in OFBiz has never supported port offset
- Jacques thinks that maybe using a port offset for tests will fix the
problem but he's unsure why

Is that mostly correct Jacques?
Almost, It's not that I'm unsure, actually I tried this weekend to use portoffset in Gradle versions. From the documentation, it's theoretically 
possible but does not work OOTB (I agree it's a complicated matter)
So I  committed r1780660  and locally hardcoded 8080 port changes to 8081 in XML files serviceengine.xml, services_test.xml and axis2.xml w/o success 
when running tests.


Then I thought more at the problem and I see now 2 options:
1) Infra does not need to have always Tomcat using the 8080 port on Buildbot hosts, problem resolved. I asked a question in the related infra: 
https://issues.apache.org/jira/browse/INFRA-13402
2) Infra needs to have always Tomcat using the 8080 port on Buildbot hosts. Then, it's maybe possible, as Taher suggested, to get back to the previous 
behaviour were tests were not using/blocking the 8080 port. Taher suggested to have a look into config.xml...


I first wait an answer to 1), then I'll consider 2)

Note though that it would be nice to not use/block ports during tests, as it was before Gradle. Then you can use another OFBiz instance while running 
tests, and vice-versa. I don't know if it's me, but it seems that I'm rehearsing the same things :/



Is there a possibility that buildbot isn't correctly shutting down OFBiz
from the previous test run and the ports are being left open?  Just a
guess, I don't know much about buildbot but that's the usual cause of the
default ports being unavailable in my experience.


Infra said in INFRA-13402 that it's due to Tomcat being puppetized, please read 
INFRA-13402

Jacques


Regards
Scott

On 30 January 2017 at 21:08, Jacques Le Roux 
wrote:


Come on Taher,

As I said below (my last message) BuildBot is only revealing a symptom.

I already explained in this thread http://markmail.org/message/h4
i7cn4i2btugdwn:

>

I suggest that you test by yourself to be convinced.

I also wrote in this same email <>

I did, now waiting their answer... and focusing on other matters in the
meantime...

Jacques


Le 29/01/2017 à 14:27, Taher Alkhateeb a écrit :


What does gradle have to do with blocking these ports? This is stuff
related to Tomcat. There is nothing in both ant and gradle that has
anything to do with these ports afaik.

On Jan 29, 2017 4:16 PM, "Jacques Le Roux" 
wrote:

Taher,

I did not say that "ant run-tests" can use portoffset. Indeed it's not,
and I was overzealous when, long ago and yesterday in r1780660, I changed
the Java code of tests for that (related with portoffset). Because I did
not change how the tests are running in pre Gradle versions. Actually I
was
then unsure and preferred to cover all cases. So, I repeat: we never
use/block ports (at least 8080 and I guess 8443) when running tests in
pre
Gradle versions.

For instance if you look for

f_ofb_15.addStep(Compile(command=["ant" , "load-demo"],
and
f_ofb_15.addStep(Compile(command=["ant" , "run-tests"],

in https://svn.apache.org/repos/infra/infrastructure/buildbot/a
egis/buildmaster/master1/projects/ofbiz.conf (for committers only)

You will see that we don't use portoffset in Buildbot and it works well:

https://ci.apache.org/projects/ofbiz/logs/15.12/html/ (ran yesterday)

But since Gradle migration something has surely changed. As Buildbot
shows
(it's a side effect here, but it's also Buildbot role to track
regressions), the ports are used(?)/blocked when running tests in post
Gradle versions.
I believe the best for us is to remove that, if it's possible. I'll have
a
look in Config.java. I'll not feel offended if someone beats me on it...

Thanks

Jacques


Le 29/01/2017 à 11:12, Taher Alkhateeb a écrit :

Okay, thank you for the efforts Jacques.

The only thing that I suspect is related might be in Config.java where
the
portoffset is evaluated. I don't think I've changed the logic, and so I
suspect that it is not related to Gradle. If the tests do not run on a
portoffset, then I suspect perhaps they don't do the same on ant either.

On Sun, Jan 29, 2017 at 12:57 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Taher,


Prior to Gradle migration we were not using the 8080 port during tests.
For instance we could have an OFBiz instance running, playing with its
UI
and then run tests on another instance or vice-versa.

This is no longer possible because now the port 8080 (and others) are
kept
open while running tests. So far it

Re: buildbot failure in on ofbiz-trunk

2017-01-30 Thread Scott Gray 
Try and be patient Jacques, I'm also having trouble understanding what you
are saying.

Here's what I've been able to understand so far:
- Pre-gradle OFBiz tests run fine on buildbot
- Gradle OFBiz fails on buildbot with a complaint that the default ports
are in use
- The test framework in OFBiz has never supported port offset
- Jacques thinks that maybe using a port offset for tests will fix the
problem but he's unsure why

Is that mostly correct Jacques?
Is there a possibility that buildbot isn't correctly shutting down OFBiz
from the previous test run and the ports are being left open?  Just a
guess, I don't know much about buildbot but that's the usual cause of the
default ports being unavailable in my experience.

Regards
Scott

On 30 January 2017 at 21:08, Jacques Le Roux 
wrote:

> Come on Taher,
>
> As I said below (my last message) BuildBot is only revealing a symptom.
>
> I already explained in this thread http://markmail.org/message/h4
> i7cn4i2btugdwn:
>
> < For instance we could have an OFBiz instance running, playing with its UI
> and then run tests on another instance or vice-versa.
> This is no longer possible because now the port 8080 (and others) are kept
> open while running tests. So far it was only a "small" annoyance, but it's
> now blocking BuildBot because infra puppetized the BuildBot slaves
> https://s.apache.org/pWQD.>>
>
> I suggest that you test by yourself to be convinced.
>
> I also wrote in this same email < infra why Tomcat is always running on these hosts...>>
>
> I did, now waiting their answer... and focusing on other matters in the
> meantime...
>
> Jacques
>
>
> Le 29/01/2017 à 14:27, Taher Alkhateeb a écrit :
>
>> What does gradle have to do with blocking these ports? This is stuff
>> related to Tomcat. There is nothing in both ant and gradle that has
>> anything to do with these ports afaik.
>>
>> On Jan 29, 2017 4:16 PM, "Jacques Le Roux" 
>> wrote:
>>
>> Taher,
>>>
>>> I did not say that "ant run-tests" can use portoffset. Indeed it's not,
>>> and I was overzealous when, long ago and yesterday in r1780660, I changed
>>> the Java code of tests for that (related with portoffset). Because I did
>>> not change how the tests are running in pre Gradle versions. Actually I
>>> was
>>> then unsure and preferred to cover all cases. So, I repeat: we never
>>> use/block ports (at least 8080 and I guess 8443) when running tests in
>>> pre
>>> Gradle versions.
>>>
>>> For instance if you look for
>>>
>>> f_ofb_15.addStep(Compile(command=["ant" , "load-demo"],
>>> and
>>> f_ofb_15.addStep(Compile(command=["ant" , "run-tests"],
>>>
>>> in https://svn.apache.org/repos/infra/infrastructure/buildbot/a
>>> egis/buildmaster/master1/projects/ofbiz.conf (for committers only)
>>>
>>> You will see that we don't use portoffset in Buildbot and it works well:
>>>
>>> https://ci.apache.org/projects/ofbiz/logs/15.12/html/ (ran yesterday)
>>>
>>> But since Gradle migration something has surely changed. As Buildbot
>>> shows
>>> (it's a side effect here, but it's also Buildbot role to track
>>> regressions), the ports are used(?)/blocked when running tests in post
>>> Gradle versions.
>>> I believe the best for us is to remove that, if it's possible. I'll have
>>> a
>>> look in Config.java. I'll not feel offended if someone beats me on it...
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>> Le 29/01/2017 à 11:12, Taher Alkhateeb a écrit :
>>>
>>> Okay, thank you for the efforts Jacques.

 The only thing that I suspect is related might be in Config.java where
 the
 portoffset is evaluated. I don't think I've changed the logic, and so I
 suspect that it is not related to Gradle. If the tests do not run on a
 portoffset, then I suspect perhaps they don't do the same on ant either.

 On Sun, Jan 29, 2017 at 12:57 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 Hi Taher,

> Prior to Gradle migration we were not using the 8080 port during tests.
> For instance we could have an OFBiz instance running, playing with its
> UI
> and then run tests on another instance or vice-versa.
>
> This is no longer possible because now the port 8080 (and others) are
> kept
> open while running tests. So far it was only a "small" annoyance, but
> it's
> now blocking BuildBot because infra puppetized the BuildBot slaves
> https://s.apache.org/pWQD.
>
> And, I don't know why and this could be a question to infra, for a
> reason
> there is always a Tomcat instance running on port 8080 these hosts
> https://s.apache.org/iSaN
>
> I thought we could bypass this issue by using portoffset with
> testIntegration task since it's now required. But I just tested locally
> and
> it seems to not work. I'm not quite sure and will try a last thing
> directly
> "on" Buildbot. If it does not work we have to think about removing this

Re: buildbot failure in on ofbiz-trunk

2017-01-30 Thread Jacques Le Roux 

Come on Taher,

As I said below (my last message) BuildBot is only revealing a symptom.

I already explained in this thread http://markmail.org/message/h4i7cn4i2btugdwn:

>


I suggest that you test by yourself to be convinced.

I also wrote in this same email <>

I did, now waiting their answer... and focusing on other matters in the 
meantime...

Jacques

Le 29/01/2017 à 14:27, Taher Alkhateeb a écrit :

What does gradle have to do with blocking these ports? This is stuff
related to Tomcat. There is nothing in both ant and gradle that has
anything to do with these ports afaik.

On Jan 29, 2017 4:16 PM, "Jacques Le Roux" 
wrote:


Taher,

I did not say that "ant run-tests" can use portoffset. Indeed it's not,
and I was overzealous when, long ago and yesterday in r1780660, I changed
the Java code of tests for that (related with portoffset). Because I did
not change how the tests are running in pre Gradle versions. Actually I was
then unsure and preferred to cover all cases. So, I repeat: we never
use/block ports (at least 8080 and I guess 8443) when running tests in pre
Gradle versions.

For instance if you look for

f_ofb_15.addStep(Compile(command=["ant" , "load-demo"],
and
f_ofb_15.addStep(Compile(command=["ant" , "run-tests"],

in https://svn.apache.org/repos/infra/infrastructure/buildbot/a
egis/buildmaster/master1/projects/ofbiz.conf (for committers only)

You will see that we don't use portoffset in Buildbot and it works well:

https://ci.apache.org/projects/ofbiz/logs/15.12/html/ (ran yesterday)

But since Gradle migration something has surely changed. As Buildbot shows
(it's a side effect here, but it's also Buildbot role to track
regressions), the ports are used(?)/blocked when running tests in post
Gradle versions.
I believe the best for us is to remove that, if it's possible. I'll have a
look in Config.java. I'll not feel offended if someone beats me on it...

Thanks

Jacques


Le 29/01/2017 à 11:12, Taher Alkhateeb a écrit :


Okay, thank you for the efforts Jacques.

The only thing that I suspect is related might be in Config.java where the
portoffset is evaluated. I don't think I've changed the logic, and so I
suspect that it is not related to Gradle. If the tests do not run on a
portoffset, then I suspect perhaps they don't do the same on ant either.

On Sun, Jan 29, 2017 at 12:57 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Taher,

Prior to Gradle migration we were not using the 8080 port during tests.
For instance we could have an OFBiz instance running, playing with its UI
and then run tests on another instance or vice-versa.

This is no longer possible because now the port 8080 (and others) are
kept
open while running tests. So far it was only a "small" annoyance, but
it's
now blocking BuildBot because infra puppetized the BuildBot slaves
https://s.apache.org/pWQD.

And, I don't know why and this could be a question to infra, for a reason
there is always a Tomcat instance running on port 8080 these hosts
https://s.apache.org/iSaN

I thought we could bypass this issue by using portoffset with
testIntegration task since it's now required. But I just tested locally
and
it seems to not work. I'm not quite sure and will try a last thing
directly
"on" Buildbot. If it does not work we have to think about removing this
need of open ports while running tests, IOW to remove this regression
introduced with Gradle.

Before anything else, I will though ask infra why Tomcat is always
running
on these hosts...

Jacques


Le 27/01/2017 à 18:15, Taher Alkhateeb a écrit :

Why do we need to run the tests on portoffset?

On Fri, Jan 27, 2017 at 7:48 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Ah, I forgot to say, that I have dropped BuildBot support for R12 and
R13.


Also that the pre-Gradle versions don't need portoffset



Le 27/01/2017 à 05:29, Jacques Le Roux a écrit :

Le 27/01/2017 à 05:14, Jacques Le Roux a écrit :


But in the case of running integration tests with a portoffset we have


an issue which is blocking BuildBot now for trunk and

R16


Jacques

Re: buildbot failure in on ofbiz-branch14

2017-01-30 Thread Jacques Le Roux 

Thanks Nicolas,

Yes, it's only this test failing and only in this branch

Jacques


Le 29/01/2017 à 17:30, Nicolas Malin a écrit :

Jacques I haven't build error localy on the branch 14.12, but one unit test 
failed

baseteststestConvertOperatorSubstitutionsFailureall converions expected:<...wo || three > four >[=] five < six <= seven> but was:<...wo 
|| three > four >[eq] five < six <= seven>


junit.framework.ComparisonFailure: all converions expected:<...wo || three > four >[=] five < six <= seven> but was:<...wo || three > four >[eq] 
five < six <= seven>

at 
org.ofbiz.base.test.GenericTestCaseBase.assertEquals(GenericTestCaseBase.java:313)
at 
org.ofbiz.base.util.test.StringUtilTests.testConvertOperatorSubstitutions(StringUtilTests.java:269)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:343)
at org.ofbiz.base.start.Start.start(Start.java:369)
at org.ofbiz.base.start.Start.main(Start.java:136)

This isn't related to the r1780696, I will search the reason

Nicolas


Le 29/01/2017 à 14:20, Jacques Le Roux a écrit :

https://ci.apache.org/builders/ofbiz-branch14/builds/329 (r1780696) is also 
failing locally

But weirdly I get the same error when reverting to r1779724 (previous commit) when it passed in Buildbot 
https://ci.apache.org/builders/ofbiz-branch14/builds/328


I thought it was an issue with Buildbot or r1780696, now I'm confused :/

Help appreciated...

Jacques

Le 28/01/2017 à 16:26, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbiz-branch14 while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbiz-branch14/builds/329

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz14-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release14.12] 1780696
Blamelist: nmalin

BUILD FAILED: failed compile_1

Sincerely,
  -The Buildbot