Groovy compilation and @CompileStatic

[Jacques Le Roux]

Hi,

With https://github.com/apache/ofbiz-framework/commit/231650e1b6 I fixed few errors that would not happen if we were using @CompileStatic  in Groovy 
files as mentioned at

https://stackoverflow.com/questions/57982247/groovy-compiler-and-non-existing-call-method

I vaguely remember having using it before it was incorporated in Groovy.
It was then with a Groovy fork and if IIRW it was slow or/and not totally ready 
(was arounf 2012/2013 IIRW)

Has someone tried to using it with a large number of Groovy files, like in 
OFBiz (600+  files) and if so how was the experience?

This said, if it's reasonable I wonder if we should not try to use it, at least 
temporarily, after our migration from Minilang to Groovy.

I tried a bit but it's not that easy because we have some (or a lot of) files which are not classes so CompileStatic  fails there, and correctly 
changing all files takes time...


Another question: what has refrained us to make all Groovy scripts as classes, 
if there is a reason?

TIA for enlightenment

Jacques
PS: I regularly (almost weekly) check the trunk demo error.logs. I'm happy to 
say that it's much more clean than it was months ago.

Re: Groovy integration tests

[Jacques Le Roux]

Hi Gil, Nicolas,

I agree it was a good thing to do. We just missed some information and 
documentation.
I have added some at OFBIZ-12320

I have also replaced all groovy-test-suite by junit-test-suite in OOTB code.

I still wonder why Eclipse proposes but does not accept groovy-test-suite as a 
right token and shows this message:

   <>

when in https://ofbiz.apache.org/dtds/test-suite.xsd 
<https://ofbiz.apache.org/dtds/test-suite.xsd> there is no important
differences between junit-test-suite and groovy-test-suite definitions

Actually it's not too bad for committers. It makes you wonder and read the documentation. So learn that groovy-test-suite should better not used in 
production.


TIA

Jacques

Le 09/09/2021 à 09:43, Nicolas Malin a écrit :

I endorse the words,

I currently implement some new test for
https://issues.apache.org/jira/browse/OFBIZ-6988, and after 3 hours to
build ofbiz, it's really boring without clear most valuable.

If for technical best practice it's better to keep test compile, it's
possible when you test write is terminate to move the groovy-test-suite
to junit-test-suite, so no reason to remove the possibility to write
test as script.

Nicolas

On 08/09/2021 15:30, Gil Portenseigne wrote:

Hello,

Currently using release 18.12 for some project we got the habit to
develop using integration test while developing in groovy.

For that usage we use mainly :
 groovy-test-suite

That allow coding tests in groovy script that do not need to be compiled
for their execution and executing them from webtools [1] (small
improvement will be contributed soon), there is no need to reboot the
local dev OFBiz instance for each modification in that test.

But these type of test has been removed with OFBIZ-11165 [2], while I
thinks that these resources are better compiled, during development
process, not having to restart OFBiz is nice.

So if nobody is against, I will reintroduce it in trunk with a note
explaining the `dev` usage.

WDYT

Regards,

Gil

[1]https://localhost:8443/webtools/control/TestSuiteInfo
[2]https://issues.apache.org/jira/browse/OFBIZ-11165

Re: Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Sorry for the buzz (and multiple description editions), it seems easier than I 
thought...

Le 01/04/2024 à 12:55, Jacques Le Roux a écrit :

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

Re: Debugging Groovy in Eclipse with JDK 17

[Jacques Le Roux]

Hi Michael,

Using F6 is behaving weirdly at CommunicationEventServices.groovy[489].
To be clear: "the Map vs def issue" directly steps out to the caller 
(GroovyEngine.java), where the exception is thrown.
So the lines below 489 seems not executed, not even the return.

So I changed from Map to def, to check that.
Like before, the debugger does not stop at 
CommunicationEventServices.groovy[489] when disabling the breakpoint at 
GroovyEngine.java[110].
When enabling it and using F5/F6/F7 keys, the behaviour is the same than with 
Map.

So I still don't understand this point (why line between 489 and the return 
seems not executed). But that's not our real issue at this stage.
Note: I understand it's a closure where return is inside, but that still don't explain the phenomenon to me. Why the rest of the closure is bypassed, 
maybe a Groovy bug or, more likely, an Eclipse debugger interpretation?


Thanks for your efforts (you can neglect the last point, more for me to 
remember ;)

Jacques

Le 22/04/2023 à 20:56, michael.br...@ecomify.de a écrit :

Hi Jacques,

we are working on this also, hope to share some results next week.

Best regards,
Michael



Am 22.04.2023 um 19:43 schrieb Jacques Le Roux:

Hi,

After the message I sent with subject "OFBiz 22.01 - Eclipse - Issues on setting up 
a debugging environment.":
https://lists.apache.org/thread/yxmdxy81ywwhldg8ml4foqls5df0hy8s
I applied Leila's advice, I tried many things at the point that I can't 
remember all. But here are the main ones.

I use last versions of Eclipse (2023-03) and Groovy plugins (5.0)
The issue I'm still fighting is not working breakpoints in Groovy files.

To test, I put a breakpoint at CommunicationEventServices.groovy[489],
and launchsendEmailDated service from Webtools

As breakpoints in Groovy are not working, I put one ahead in 
GroovyEngine.java[110].
 From then, using F5/F6/F7 keyboard keys, I can get into 
CommunicationEventServices.groovy::sendEmailDated

Before that, the issue I crossed was that I could not keep the relation, 
manually done as proposed by Eclipse, to the source .
BTW, that's what I was actually using before (JDK 17? Eclipse version?, etc. I 
don't know)
when I wanted to debug Groovy with breakpoints (already long ago).

So I added the "**/*.groovy" "Script Folder" using the  option "Configure Workspace 
Settings..." of the "Groovy Compiler" project properties.
Once that done the Groovy source relation stayed.

But still the breakpoint at CommunicationEventServices.groovy[489] does not 
stop the process. I have to get there using the F6 key.

I shared that in the hope that someone does better and can share.

TIA

Jacques

Re: Debugging Groovy in Eclipse with JDK 17

[michael.br...@ecomify.de]

Hi Jacques,

we are working on this also, hope to share some results next week.

Best regards,
Michael 


> Am 22.04.2023 um 19:43 schrieb Jacques Le Roux :
> 
> Hi,
> 
> After the message I sent with subject "OFBiz 22.01 - Eclipse - Issues on 
> setting up a debugging environment.":
> https://lists.apache.org/thread/yxmdxy81ywwhldg8ml4foqls5df0hy8s
> I applied Leila's advice, I tried many things at the point that I can't 
> remember all. But here are the main ones.
> 
> I use last versions of Eclipse (2023-03) and Groovy plugins (5.0)
> The issue I'm still fighting is not working breakpoints in Groovy files.
> 
> To test, I put a breakpoint at CommunicationEventServices.groovy[489],
> and launchsendEmailDated service from Webtools
> 
> As breakpoints in Groovy are not working, I put one ahead in 
> GroovyEngine.java[110].
> From then, using F5/F6/F7 keyboard keys, I can get into 
> CommunicationEventServices.groovy::sendEmailDated
> 
> Before that, the issue I crossed was that I could not keep the relation, 
> manually done as proposed by Eclipse, to the source .
> BTW, that's what I was actually using before (JDK 17? Eclipse version?, etc. 
> I don't know)
> when I wanted to debug Groovy with breakpoints (already long ago).
> 
> So I added the "**/*.groovy" "Script Folder" using the  option "Configure 
> Workspace Settings..." of the "Groovy Compiler" project properties.
> Once that done the Groovy source relation stayed.
> 
> But still the breakpoint at CommunicationEventServices.groovy[489] does not 
> stop the process. I have to get there using the F6 key.
> 
> I shared that in the hope that someone does better and can share.
> 
> TIA
> 
> Jacques
> 

Debugging Groovy in Eclipse with JDK 17

[Jacques Le Roux]

Hi,

After the message I sent with subject "OFBiz 22.01 - Eclipse - Issues on setting up 
a debugging environment.":
https://lists.apache.org/thread/yxmdxy81ywwhldg8ml4foqls5df0hy8s
I applied Leila's advice, I tried many things at the point that I can't 
remember all. But here are the main ones.

I use last versions of Eclipse (2023-03) and Groovy plugins (5.0)
The issue I'm still fighting is not working breakpoints in Groovy files.

To test, I put a breakpoint at CommunicationEventServices.groovy[489],
and launchsendEmailDated service from Webtools

As breakpoints in Groovy are not working, I put one ahead in 
GroovyEngine.java[110].
From then, using F5/F6/F7 keyboard keys, I can get into 
CommunicationEventServices.groovy::sendEmailDated

Before that, the issue I crossed was that I could not keep the relation, 
manually done as proposed by Eclipse, to the source .
BTW, that's what I was actually using before (JDK 17? Eclipse version?, etc. I 
don't know)
when I wanted to debug Groovy with breakpoints (already long ago).

So I added the "**/*.groovy" "Script Folder" using the  option "Configure Workspace 
Settings..." of the "Groovy Compiler" project properties.
Once that done the Groovy source relation stayed.

But still the breakpoint at CommunicationEventServices.groovy[489] does not 
stop the process. I have to get there using the F6 key.

I shared that in the hope that someone does better and can share.

TIA

Jacques

Re: Calling groovy from a form field

[Ernest Hocking]

Hi Danel

here's the solution that worked:

   






I also found an example in the codebase under Catalog -> Stores -> facility
that was useful

thanks for the pointers

kind regards

Ernest

On Tue, Jan 24, 2023 at 2:52 PM Daniel Watford  wrote:

> Hi Ernest,
>
> I'm not aware of any examples in OFBiz that exactly fit your use case. You
> may implement a solution using javascript to send your request to the
> testCalc service and then apply the results to the current form.
>
> An example of executing javascript from clicking a hyperlink can be seen in
> the Example plugin:
> https://demo-next.ofbiz.apache.org/example/control/FormWidgetExamples and
> is defined by the following element in FormWidgetExampleForms.xml:
>
>  title="${uiLabelMap.SignedInAuthToAnotherDomain}"
> widget-style="buttontext"
> tooltip="${uiLabelMap.SignedInAuthToAnotherDomainTooltip}">
>  description="${uiLabelMap.TargetURL}" target="${targetUrl}"/>
> 
>
>
> Another approach, albeit not one I have experimented with, is the
> on-event-update-area element. See example
> https://demo-next.ofbiz.apache.org/example/control/authview/findExampleAjax
> .
> In this example, screen ExampleAjaxScreens.xml#AjaxExample is rendered
> containing screens ListExampleFormOnly and CreateExampleFormOnly.
>
> Screen CreateExampleFormOnly includes form
> ExampleForms.xml#EditExampleBackgroundSubmit.
>
> Form EditExampleBackgroundSubmit has an on-event-update-area element
> directing OFBiz to update the ListExamplesAjax area (i.e. the form on the
> ListExampleFormOnly screen) when the EditExampleBackgroundSubmit form is
> submitted.
>
> If you trace the network calls in your web browser's development tools, you
> will see that submitting the EditExampleBackgroundSubmit form does not
> reload the page. Instead a post request is made to endpoint
> createExampleAjax to create the new Example record. A post is then made to
> the ListFormExampleOnly endpoint, retrieving the new contents of the list
> and displaying on the page.
>
> There might be a solution for your use case where your Calculate C button
> is on a small form adjacent to your Product Measures form. The form
> containing the button would have on-event-update-area configured to update
> the Product Measures form following a submit event.
>
> Please let us know how you get on.
>
> Dan.
>
> On Sun, 22 Jan 2023 at 04:19, Ernest Hocking 
> wrote:
>
> > Hi everyone
> >
> > I'd like to use groovy to implement some business logic and call that
> logic
> > from a button in a form.
> >
> > E.g Add a button on the product measures form to calculate  the volume
> > given a product's dimensions..  I've tried
> >
> > 
> >  > also-hidden="false">
> > 
> >
> > 
> > 
> > I can call/test the service "testCalc" from webtools etc but not use the
> > button.
> >
> > Can anyone point me to an example in the existing code base that I can
> use
> > as a reference model.
> >
> > thanks in advance
> >
> > Ernest
> >
>
>
> --
> Daniel Watford
>

Re: Calling groovy from a form field

[Daniel Watford]

Hi Ernest,

I'm not aware of any examples in OFBiz that exactly fit your use case. You
may implement a solution using javascript to send your request to the
testCalc service and then apply the results to the current form.

An example of executing javascript from clicking a hyperlink can be seen in
the Example plugin:
https://demo-next.ofbiz.apache.org/example/control/FormWidgetExamples and
is defined by the following element in FormWidgetExampleForms.xml:






Another approach, albeit not one I have experimented with, is the
on-event-update-area element. See example
https://demo-next.ofbiz.apache.org/example/control/authview/findExampleAjax.
In this example, screen ExampleAjaxScreens.xml#AjaxExample is rendered
containing screens ListExampleFormOnly and CreateExampleFormOnly.

Screen CreateExampleFormOnly includes form
ExampleForms.xml#EditExampleBackgroundSubmit.

Form EditExampleBackgroundSubmit has an on-event-update-area element
directing OFBiz to update the ListExamplesAjax area (i.e. the form on the
ListExampleFormOnly screen) when the EditExampleBackgroundSubmit form is
submitted.

If you trace the network calls in your web browser's development tools, you
will see that submitting the EditExampleBackgroundSubmit form does not
reload the page. Instead a post request is made to endpoint
createExampleAjax to create the new Example record. A post is then made to
the ListFormExampleOnly endpoint, retrieving the new contents of the list
and displaying on the page.

There might be a solution for your use case where your Calculate C button
is on a small form adjacent to your Product Measures form. The form
containing the button would have on-event-update-area configured to update
the Product Measures form following a submit event.

Please let us know how you get on.

Dan.

On Sun, 22 Jan 2023 at 04:19, Ernest Hocking 
wrote:

> Hi everyone
>
> I'd like to use groovy to implement some business logic and call that logic
> from a button in a form.
>
> E.g Add a button on the product measures form to calculate  the volume
> given a product's dimensions..  I've tried
>
> 
>  also-hidden="false">
> 
>
> 
> 
> I can call/test the service "testCalc" from webtools etc but not use the
> button.
>
> Can anyone point me to an example in the existing code base that I can use
> as a reference model.
>
> thanks in advance
>
> Ernest
>


-- 
Daniel Watford

Calling groovy from a form field

[ernest.hock...@computer.org]

  Hi everyone

I'd like to use groovy to implement some business logic and call that logic
from a button in a form.

E.g Add a button on the product measures form to calculate  the volume
given a product's dimensions..  I've tried




   


I can call/test the service "testCalc" from webtools etc but not use the
button.

Can anyone point me to an example in the existing code base that I can use
as a reference model.

thanks in advance

Ernest

Calling groovy from a form field

[Ernest Hocking]

Hi everyone

I'd like to use groovy to implement some business logic and call that logic
from a button in a form.

E.g Add a button on the product measures form to calculate  the volume
given a product's dimensions..  I've tried




   


I can call/test the service "testCalc" from webtools etc but not use the
button.

Can anyone point me to an example in the existing code base that I can use
as a reference model.

thanks in advance

Ernest

Re: Groovy Sandboxing

[Jacques Le Roux]

Hi Nico,

I see no reasons to fear about impersonate right now. It would be a post-auth 
issue anyway...

Thanks

Jacques

Le 27/09/2021 à 09:37, Nicolas Malin a écrit :

I agree with you Jacques.

If some fear are present, as impersonate we can load a specific
permission and add a property that disable by default this function.

Nicolas

On 21/09/2021 08:06, Jacques Le Roux wrote:

Hi,

The security reporter 'thiscodecc" created OFBIZ-12305 about "Groovy
Program sandbox bypass". He suggested to use one of "the very mature
solutions on the groovy sandbox on the market. You can refer to it.".

I had a look. The best article was from Cédric Champeau:
https://melix.github.io/blog/2015/03/sandboxing.htmland clearly he
does not advocate for "mature solutions on the groovy sandbox on the
market".

So I rather fixed the issue with a "simple" and pragmatic approach by
reusing the work I already did with SecuredUpload::isValidTextFile. I
refactored it and created the public SecuredUpload::isValidText.

Finally, with OFBIZ-12324 I extracted the webshell tokens in the
deniedWebShellTokens property in security.properties.

I had a deeper look at Cédric's article and I'm now convinced that,
because only ProgramExport in Webtool was concerned we don't need to
worry about Groovy Sandboxing.

If you don't think so, please explain why

TIA

Jacques

Re: Groovy Sandboxing

[Nicolas Malin]

I agree with you Jacques.

If some fear are present, as impersonate we can load a specific
permission and add a property that disable by default this function.

Nicolas

On 21/09/2021 08:06, Jacques Le Roux wrote:
> Hi,
>
> The security reporter 'thiscodecc" created OFBIZ-12305 about "Groovy
> Program sandbox bypass". He suggested to use one of "the very mature
> solutions on the groovy sandbox on the market. You can refer to it.".
>
> I had a look. The best article was from Cédric Champeau:
> https://melix.github.io/blog/2015/03/sandboxing.htmland clearly he
> does not advocate for "mature solutions on the groovy sandbox on the
> market".
>
> So I rather fixed the issue with a "simple" and pragmatic approach by
> reusing the work I already did with SecuredUpload::isValidTextFile. I
> refactored it and created the public SecuredUpload::isValidText.
>
> Finally, with OFBIZ-12324 I extracted the webshell tokens in the
> deniedWebShellTokens property in security.properties.
>
> I had a deeper look at Cédric's article and I'm now convinced that,
> because only ProgramExport in Webtool was concerned we don't need to
> worry about Groovy Sandboxing.
>
> If you don't think so, please explain why
>
> TIA
>
> Jacques
>

Groovy Sandboxing

[Jacques Le Roux]

Hi,

The security reporter 'thiscodecc" created OFBIZ-12305 about "Groovy Program sandbox bypass". He suggested to use one of "the very mature solutions on 
the groovy sandbox on the market. You can refer to it.".


I had a look. The best article was from Cédric Champeau: https://melix.github.io/blog/2015/03/sandboxing.htmland clearly he does not advocate for 
"mature solutions on the groovy sandbox on the market".


So I rather fixed the issue with a "simple" and pragmatic approach by reusing the work I already did with SecuredUpload::isValidTextFile. I refactored 
it and created the public SecuredUpload::isValidText.


Finally, with OFBIZ-12324 I extracted the webshell tokens in the 
deniedWebShellTokens property in security.properties.

I had a deeper look at Cédric's article and I'm now convinced that, because only ProgramExport in Webtool was concerned we don't need to worry about 
Groovy Sandboxing.


If you don't think so, please explain why

TIA

Jacques

Re: Groovy integration tests

[Nicolas Malin]

I endorse the words,

I currently implement some new test for
https://issues.apache.org/jira/browse/OFBIZ-6988, and after 3 hours to
build ofbiz, it's really boring without clear most valuable.

If for technical best practice it's better to keep test compile, it's
possible when you test write is terminate to move the groovy-test-suite
to junit-test-suite, so no reason to remove the possibility to write
test as script.

Nicolas

On 08/09/2021 15:30, Gil Portenseigne wrote:
> Hello,
>
> Currently using release 18.12 for some project we got the habit to
> develop using integration test while developing in groovy.
>
> For that usage we use mainly :
> groovy-test-suite
>
> That allow coding tests in groovy script that do not need to be compiled
> for their execution and executing them from webtools [1] (small
> improvement will be contributed soon), there is no need to reboot the
> local dev OFBiz instance for each modification in that test.
>
> But these type of test has been removed with OFBIZ-11165 [2], while I
> thinks that these resources are better compiled, during development
> process, not having to restart OFBiz is nice.
>
> So if nobody is against, I will reintroduce it in trunk with a note
> explaining the `dev` usage.
>
> WDYT
>
> Regards,
>
> Gil
>
> [1] https://localhost:8443/webtools/control/TestSuiteInfo
> [2] https://issues.apache.org/jira/browse/OFBIZ-11165

Groovy integration tests

[Gil Portenseigne]

Hello,

Currently using release 18.12 for some project we got the habit to
develop using integration test while developing in groovy.

For that usage we use mainly :
groovy-test-suite

That allow coding tests in groovy script that do not need to be compiled
for their execution and executing them from webtools [1] (small
improvement will be contributed soon), there is no need to reboot the
local dev OFBiz instance for each modification in that test.

But these type of test has been removed with OFBIZ-11165 [2], while I
thinks that these resources are better compiled, during development
process, not having to restart OFBiz is nice.

So if nobody is against, I will reintroduce it in trunk with a note
explaining the `dev` usage.

WDYT

Regards,

Gil

[1] https://localhost:8443/webtools/control/TestSuiteInfo
[2] https://issues.apache.org/jira/browse/OFBIZ-11165


signature.asc
Description: PGP signature

Re: [ofbiz-framework] branch trunk updated: Improved: Convert EntitySyncServices.xml mini-lang to groovy

[Jacques Le Roux]

Hi Aayush,

Please help yourself: https://ofbiz.apache.org/mailing-lists.html

Jacques

Le 30/05/2021 à 09:17, Aayush Gupta a écrit :

Hello guys
Please unsubscribe from these mails
Thanks

On Sun, 30 May 2021, 12:43 pm ,  wrote:


This is an automated email from the ASF dual-hosted git repository.

danwatford pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new c654d9b  Improved: Convert EntitySyncServices.xml mini-lang to
groovy
c654d9b is described below

commit c654d9bbcc31f2b3ea218914a56a9569c21d0f8d
Author: Daniel Watford 
AuthorDate: Sun May 30 08:13:23 2021 +0100

 Improved: Convert EntitySyncServices.xml mini-lang to groovy

 (OFBIZ-11660)

 removed: EntitySyncServices.xml
 added: EntitySyncServices.groovy
 modified: services.xml to reflect the change from minilang to groovy
for:
 - entitySyncPermissionCheck
 - resetEntitySyncStatus
 modified: webtools/controller.xml to reflect changed request-map and
event type regarding reset of EntitySyncStatus
 modified: webtools/widget/EntitySyncForms.xml to reflect changed
target regarding reset of EntitySyncStatus

 Thanks: Pierre Smits for implementation
---
  .../groovyScripts/EntitySyncServices.groovy| 32
+++
  .../entityext/minilang/EntitySyncServices.xml  | 36
--
  framework/entityext/servicedef/services.xml|  8 ++---
  .../webapp/webtools/WEB-INF/controller.xml |  4 +--
  framework/webtools/widget/EntitySyncForms.xml  |  2 +-
  5 files changed, 39 insertions(+), 43 deletions(-)

diff --git a/framework/entityext/groovyScripts/EntitySyncServices.groovy
b/framework/entityext/groovyScripts/EntitySyncServices.groovy
new file mode 100644
index 000..8acea4e
--- /dev/null
+++ b/framework/entityext/groovyScripts/EntitySyncServices.groovy
@@ -0,0 +1,32 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+def entitySyncPermissionCheck() {
+parameters.primaryPermission = "ENTITY_SYNC"
+Map serviceResult = run service: "genericBasePermissionCheck", with:
parameters
+return serviceResult
+}
+
+def resetEntitySyncStatus() {
+   entitySyncRecord = from("EntitySync").where("entitySyncId",
parameters.entitySyncId).queryOne()
+if(entitySyncRecord &&
"ESR_RUNNING".equals(entitySyncRecord.runStatusId)) {
+entitySyncRecord.runStatusId = "ESR_NOT_STARTED"
+entitySyncRecord.store()
+}
+}
diff --git a/framework/entityext/minilang/EntitySyncServices.xml
b/framework/entityext/minilang/EntitySyncServices.xml
deleted file mode 100644
index a134c26..000
--- a/framework/entityext/minilang/EntitySyncServices.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-
-
-
-http://www.w3.org/2001/XMLSchema-instance";
-xmlns="http://ofbiz.apache.org/Simple-Method";
xsi:schemaLocation="http://ofbiz.apache.org/Simple-Method
http://ofbiz.apache.org/dtds/simple-methods.xsd";>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/framework/entityext/servicedef/services.xml
b/framework/entityext/servicedef/services.xml
index 7d0951e..b95fc2d 100644
--- a/framework/entityext/servicedef/services.xml
+++ b/framework/entityext/servicedef/services.xml
@@ -224,8 +224,8 @@ under the License.

  location="org.apache.ofbiz.entityext.synchronization.EntitySyncServices"
invoke="cleanSyncRemoveInfo" auth="true" transaction-timeout="600">
  Clean EntitySyncRemove Info - Generally should be
run asynchronously after each sync run, or periodically run on a
schedule
  
-
+
  Generally run manually to reset the status of an
EntitySync when it has "crashed". Update a EntitySync, set the Status to
ESR_NOT_STARTED, but ONLY if running (ie in ESR_RUNNING)
  
  
@@ -446,8 +446,8 @@ under the License.
  Delete a ServerHitType
  
  
-
+
  Entity sync permi

Re: [ofbiz-framework] branch trunk updated: Improved: Convert EntitySyncServices.xml mini-lang to groovy

[Aayush Gupta]

Hello guys
Please unsubscribe from these mails
Thanks

On Sun, 30 May 2021, 12:43 pm ,  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> danwatford pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new c654d9b  Improved: Convert EntitySyncServices.xml mini-lang to
> groovy
> c654d9b is described below
>
> commit c654d9bbcc31f2b3ea218914a56a9569c21d0f8d
> Author: Daniel Watford 
> AuthorDate: Sun May 30 08:13:23 2021 +0100
>
> Improved: Convert EntitySyncServices.xml mini-lang to groovy
>
> (OFBIZ-11660)
>
> removed: EntitySyncServices.xml
> added: EntitySyncServices.groovy
> modified: services.xml to reflect the change from minilang to groovy
> for:
> - entitySyncPermissionCheck
> - resetEntitySyncStatus
> modified: webtools/controller.xml to reflect changed request-map and
> event type regarding reset of EntitySyncStatus
> modified: webtools/widget/EntitySyncForms.xml to reflect changed
> target regarding reset of EntitySyncStatus
>
> Thanks: Pierre Smits for implementation
> ---
>  .../groovyScripts/EntitySyncServices.groovy| 32
> +++
>  .../entityext/minilang/EntitySyncServices.xml  | 36
> --
>  framework/entityext/servicedef/services.xml|  8 ++---
>  .../webapp/webtools/WEB-INF/controller.xml |  4 +--
>  framework/webtools/widget/EntitySyncForms.xml  |  2 +-
>  5 files changed, 39 insertions(+), 43 deletions(-)
>
> diff --git a/framework/entityext/groovyScripts/EntitySyncServices.groovy
> b/framework/entityext/groovyScripts/EntitySyncServices.groovy
> new file mode 100644
> index 000..8acea4e
> --- /dev/null
> +++ b/framework/entityext/groovyScripts/EntitySyncServices.groovy
> @@ -0,0 +1,32 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership.  The ASF licenses this file
> + * to you under the Apache License, Version 2.0 (the
> + * "License"); you may not use this file except in compliance
> + * with the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> + * software distributed under the License is distributed on an
> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + * KIND, either express or implied.  See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> +def entitySyncPermissionCheck() {
> +parameters.primaryPermission = "ENTITY_SYNC"
> +Map serviceResult = run service: "genericBasePermissionCheck", with:
> parameters
> +return serviceResult
> +}
> +
> +def resetEntitySyncStatus() {
> +   entitySyncRecord = from("EntitySync").where("entitySyncId",
> parameters.entitySyncId).queryOne()
> +if(entitySyncRecord &&
> "ESR_RUNNING".equals(entitySyncRecord.runStatusId)) {
> +entitySyncRecord.runStatusId = "ESR_NOT_STARTED"
> +entitySyncRecord.store()
> +}
> +}
> diff --git a/framework/entityext/minilang/EntitySyncServices.xml
> b/framework/entityext/minilang/EntitySyncServices.xml
> deleted file mode 100644
> index a134c26..000
> --- a/framework/entityext/minilang/EntitySyncServices.xml
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -
> -
> -
> -http://www.w3.org/2001/XMLSchema-instance";
> -xmlns="http://ofbiz.apache.org/Simple-Method";
> xsi:schemaLocation="http://ofbiz.apache.org/Simple-Method
> http://ofbiz.apache.org/dtds/simple-methods.xsd";>
> - short-description="Update a EntitySync, set the Status to ESR_NOT_STARTED,
> but ONLY if running (ie in ESR_RUNNING)">
> -
> - from-field="parameters.entitySyncId"/>
> - value-field="valueToStore"/>
> - value="ESR_RUNNING">
> - value="ESR_NOT_STARTED"/>
> -
> -
> -
> - short-description="Check user permission for entity sync.">
> -
> - xml-resource="component://common/minilang/permission/CommonPermissionServices.xml"/>
> -
> -
> diff --git a/framework/entityext/servicedef/services.xml
> b/framework/entityext

Re: XML to Groovy conversions

[Jacques Le Roux]

Hi Suraj,

Thanks for your suggestions, I want to add an obvious one:

Please test your changes, at least manually or by adding JUnit tests.

OFBIZ-11986 is a good example of what needs to be done else after  :/

I was actually looking for a recent more complaining message on the same subject but I could not spot it. I guess I confused with your which is not 
really complaining :)


Jacques

Le 16/05/2020 à 09:30, Suraj Khurana a écrit :

Hello team,

Recently we are working on a major refactoring task of minilnag to groovy
conversion, which is commendable. I would like to add following points to
be taken into consideration while doing the exact changes in the service:

- Check and think of possible conversion to entity-auto.
- Handle service error responses, in xml usually we skip it. It would be
great if while conversion if any service is called, its error response
should be effectively handled. Like in a single line:

serviceResult = run service: "createCustomer", with: parameters
if (!ServiceUtil.isSuccess(serviceResult)) return
error(serviceResult.errorMessage)

- Avoid unnecessary declaration of variables and the same 'serviceResult'
map can be re-used in case of multiple service calls inside the same
service.

IMO, these are very small best practices that can directly be taken care of
while conversion, will improve code quality.

Please share your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: Behavior of Groovy vs JUnit tests with test data

[Jacques Le Roux]

Hi Carsten,

Inline...

Le 08/09/2020 à 12:46, Carsten Schinzer a écrit :

Hello Jacques,


Thanks for the pointer.

My issue is that I find the XML test cases not good enough as e.g. the 
updateCustRequest service has special behaviors when cancelling or adding 
stories to a custRequest which are currently not covered by the test in XML.
Similar for the transitions between custRequestStatusIds some are forbidden and 
some are not and the test cases did not cover either.


+1 for improvement (did not review)



The issue is really that in Groovy when starting from a given data load, the 
data is not refreshed/reset after a test case is run and hence I decided to do 
the testing of services in full and plain JUnit. Others apparently have decided 
the same.


I guess those persons did that long ago and not related to the move from 
Minilang to Groovy



In the subtasks you pointed me to, the problem is circumvented by creating the 
data in a common method before running a test against it. So the data load does 
not occur via the tested location. I wanted to re-use existing test data for 
custRequest.


I was not aware of the issue refreshed/reset after a test case. Indeed we don't use that in Goovy test. Did you have a look at 
https://issues.apache.org/jira/browse/OFBIZ-9996 and http://groovy-lang.org/testing.html?




If you tell me that the intent is to also get rid of the test data defined in 
the tested, then I would be on the wrong track and need to change my code to be 
like the one you pointed me to. Is there any decision made to also get rid of 
the test data loads when migrating minilang to groovy?


I don't think a such decision has been made. Nicolas started with OFBIZ-9996. Since then few improvement has been made, but nothing related to what 
you are looking for.




Warm regards

Carsten

PS: I also find it a pity that the JIRA tickets that are distributed are 
already subtasks in Stories instead of Stories in Epics. It disallows me to 
track the work done in sufficient detail other than commenting on the subtask. 
Do you know why that has been done like this? I should possibly rather discuss 
with Pierre Smits I guess?


We don't follow Scrum in Jira. We don't use Stories and Epics. We simply create tasks to be done. Sometimes subtasks are an easy way to group the 
actions, that's it. I don't know about Pierre's availability, what would you want to discuss exactly?


HTH

Jacques






Am 08.09.2020 um 11:54 schrieb Jacques Le Roux :

Hi Carsten,

Did you have a look at the WIP under 
https://issues.apache.org/jira/browse/OFBIZ-11232 and how it's done in subtasks?

Jacques

Le 03/09/2020 à 13:43, Carsten Schinzer a écrit :

Hi all,


I did find and try the following from google search:

- wrap all the tests in a class
- tag the class with @RunWith(SpringRunner.class)
- tag every method that manipulates the entity data with 
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

This has NOT been successful, hence a strong indication that running the cases 
in Groovy will make entity data manipulations to be sticky and not reverted for 
the subsequent test case run.
I am going to rework my cases to run as JUnit test cases in a Java class.

Warm regards


Carsten


Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
:

Hi everyone,


Recently, I did find that test cases actually are much easier to write in 
Groovy and hence I started doing that, but now I stumble across the fact that 
some of the Groovy tests seem to find changes applied to entities from previous 
tests. The behavior is the following:

- I load the test data with instructions given in the tested XML
- I manipulate data in the first test data, e.g. a status on an entity
- when I run the next test case I do not get the originally loaded entity but 
the manipulated one from the previous test

This is different from JUnit in Java where the entities seem to exist as loaded 
from the testdata XML with every new test case.
It would obviously mean that I we need to implement my testing in JUnit (Java) 
rather when we want extensive testing of the services and need to start from 
the loaded data every time.

Can anyone confirm this behavior of Groovy over JUnit?
Warm regards


Carsten

Re: Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hello Jacques,


Thanks for the pointer.

My issue is that I find the XML test cases not good enough as e.g. the 
updateCustRequest service has special behaviors when cancelling or adding 
stories to a custRequest which are currently not covered by the test in XML.
Similar for the transitions between custRequestStatusIds some are forbidden and 
some are not and the test cases did not cover either.

The issue is really that in Groovy when starting from a given data load, the 
data is not refreshed/reset after a test case is run and hence I decided to do 
the testing of services in full and plain JUnit. Others apparently have decided 
the same.

In the subtasks you pointed me to, the problem is circumvented by creating the 
data in a common method before running a test against it. So the data load does 
not occur via the tested location. I wanted to re-use existing test data for 
custRequest.

If you tell me that the intent is to also get rid of the test data defined in 
the tested, then I would be on the wrong track and need to change my code to be 
like the one you pointed me to. Is there any decision made to also get rid of 
the test data loads when migrating minilang to groovy?

Warm regards


Carsten

PS: I also find it a pity that the JIRA tickets that are distributed are 
already subtasks in Stories instead of Stories in Epics. It disallows me to 
track the work done in sufficient detail other than commenting on the subtask. 
Do you know why that has been done like this? I should possibly rather discuss 
with Pierre Smits I guess?


> Am 08.09.2020 um 11:54 schrieb Jacques Le Roux :
> 
> Hi Carsten,
> 
> Did you have a look at the WIP under 
> https://issues.apache.org/jira/browse/OFBIZ-11232 and how it's done in 
> subtasks?
> 
> Jacques
> 
> Le 03/09/2020 à 13:43, Carsten Schinzer a écrit :
>> Hi all,
>> 
>> 
>> I did find and try the following from google search:
>> 
>> - wrap all the tests in a class
>> - tag the class with @RunWith(SpringRunner.class)
>> - tag every method that manipulates the entity data with 
>> @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
>> 
>> This has NOT been successful, hence a strong indication that running the 
>> cases in Groovy will make entity data manipulations to be sticky and not 
>> reverted for the subsequent test case run.
>> I am going to rework my cases to run as JUnit test cases in a Java class.
>> 
>> Warm regards
>> 
>> 
>> Carsten
>> 
>>> Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
>>> :
>>> 
>>> Hi everyone,
>>> 
>>> 
>>> Recently, I did find that test cases actually are much easier to write in 
>>> Groovy and hence I started doing that, but now I stumble across the fact 
>>> that some of the Groovy tests seem to find changes applied to entities from 
>>> previous tests. The behavior is the following:
>>> 
>>> - I load the test data with instructions given in the tested XML
>>> - I manipulate data in the first test data, e.g. a status on an entity
>>> - when I run the next test case I do not get the originally loaded entity 
>>> but the manipulated one from the previous test
>>> 
>>> This is different from JUnit in Java where the entities seem to exist as 
>>> loaded from the testdata XML with every new test case.
>>> It would obviously mean that I we need to implement my testing in JUnit 
>>> (Java) rather when we want extensive testing of the services and need to 
>>> start from the loaded data every time.
>>> 
>>> Can anyone confirm this behavior of Groovy over JUnit?
>>> Warm regards
>>> 
>>> 
>>> Carsten
>>> 

Re: Behavior of Groovy vs JUnit tests with test data

[Jacques Le Roux]

Hi Carsten,

Did you have a look at the WIP under 
https://issues.apache.org/jira/browse/OFBIZ-11232 and how it's done in subtasks?

Jacques

Le 03/09/2020 à 13:43, Carsten Schinzer a écrit :

Hi all,


I did find and try the following from google search:

- wrap all the tests in a class
- tag the class with @RunWith(SpringRunner.class)
- tag every method that manipulates the entity data with 
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

This has NOT been successful, hence a strong indication that running the cases 
in Groovy will make entity data manipulations to be sticky and not reverted for 
the subsequent test case run.
I am going to rework my cases to run as JUnit test cases in a Java class.

Warm regards


Carsten


Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
:

Hi everyone,


Recently, I did find that test cases actually are much easier to write in 
Groovy and hence I started doing that, but now I stumble across the fact that 
some of the Groovy tests seem to find changes applied to entities from previous 
tests. The behavior is the following:

- I load the test data with instructions given in the tested XML
- I manipulate data in the first test data, e.g. a status on an entity
- when I run the next test case I do not get the originally loaded entity but 
the manipulated one from the previous test

This is different from JUnit in Java where the entities seem to exist as loaded 
from the testdata XML with every new test case.
It would obviously mean that I we need to implement my testing in JUnit (Java) 
rather when we want extensive testing of the services and need to start from 
the loaded data every time.

Can anyone confirm this behavior of Groovy over JUnit?
Warm regards


Carsten

Re: Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hi all,


I did find and try the following from google search:

- wrap all the tests in a class
- tag the class with @RunWith(SpringRunner.class)
- tag every method that manipulates the entity data with 
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)

This has NOT been successful, hence a strong indication that running the cases 
in Groovy will make entity data manipulations to be sticky and not reverted for 
the subsequent test case run.
I am going to rework my cases to run as JUnit test cases in a Java class.

Warm regards


Carsten

> Am 03.09.2020 um 13:13 schrieb Carsten Schinzer 
> :
> 
> Hi everyone,
> 
> 
> Recently, I did find that test cases actually are much easier to write in 
> Groovy and hence I started doing that, but now I stumble across the fact that 
> some of the Groovy tests seem to find changes applied to entities from 
> previous tests. The behavior is the following:
> 
> - I load the test data with instructions given in the tested XML
> - I manipulate data in the first test data, e.g. a status on an entity
> - when I run the next test case I do not get the originally loaded entity but 
> the manipulated one from the previous test
> 
> This is different from JUnit in Java where the entities seem to exist as 
> loaded from the testdata XML with every new test case.
> It would obviously mean that I we need to implement my testing in JUnit 
> (Java) rather when we want extensive testing of the services and need to 
> start from the loaded data every time. 
> 
> Can anyone confirm this behavior of Groovy over JUnit?
> Warm regards
> 
> 
> Carsten
> 

Behavior of Groovy vs JUnit tests with test data

[Carsten Schinzer]

Hi everyone,


Recently, I did find that test cases actually are much easier to write in 
Groovy and hence I started doing that, but now I stumble across the fact that 
some of the Groovy tests seem to find changes applied to entities from previous 
tests. The behavior is the following:

- I load the test data with instructions given in the tested XML
- I manipulate data in the first test data, e.g. a status on an entity
- when I run the next test case I do not get the originally loaded entity but 
the manipulated one from the previous test

This is different from JUnit in Java where the entities seem to exist as loaded 
from the testdata XML with every new test case.
It would obviously mean that I we need to implement my testing in JUnit (Java) 
rather when we want extensive testing of the services and need to start from 
the loaded data every time. 

Can anyone confirm this behavior of Groovy over JUnit?
Warm regards


Carsten

XML to Groovy conversions

[Suraj Khurana]

Hello team,

Recently we are working on a major refactoring task of minilnag to groovy
conversion, which is commendable. I would like to add following points to
be taken into consideration while doing the exact changes in the service:

- Check and think of possible conversion to entity-auto.
- Handle service error responses, in xml usually we skip it. It would be
great if while conversion if any service is called, its error response
should be effectively handled. Like in a single line:

serviceResult = run service: "createCustomer", with: parameters
if (!ServiceUtil.isSuccess(serviceResult)) return
error(serviceResult.errorMessage)

- Avoid unnecessary declaration of variables and the same 'serviceResult'
map can be re-used in case of multiple service calls inside the same
service.

IMO, these are very small best practices that can directly be taken care of
while conversion, will improve code quality.

Please share your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: Upgrade Gradle and Groovy

[James Yong]

Thanks Jacques.

I have created OFBIZ-11661 for this.

Correction: Groovy version used in OFBiz trunk is 2.5.8, not 2.5.4

On 2020/05/04 13:10:42, Jacques Le Roux  wrote: 
> Hi James,
> 
> I trust a Jira fits
> 
> Thanks
> 
> Jacques
> 
> Le 04/05/2020 à 14:54, James Yong a écrit :
> > Hi all,
> >
> > Current Gradle version used in OFBiz trunk is 5.0.
> > Propose to update to Gradle 6.3 which is the current stable version.
> >
> > Gradle 6.3 requires groovy 2.5.10., but Groovy version used in OFBiz trunk 
> > is 2.5.4
> > Suggest to upgrade Groovy to 2.5.11 which is the current stable version.
> >
> > For Gradle upgrade, I run:
> > ./gradlew wrapper --gradle-version=6.3 --distribution-type=bin
> >
> > For Groovy upgrade, I updated the build.gradle with the new Groovy version.
> >
> > So far, no issue encountered with the upgrades on my side.
> >
> > Let me know if any concerns.
> > Plan to create JIRA issue for the upgrades by next week.
> >
> > Regards,
> > James
> 
> 

Re: Upgrade Gradle and Groovy

[Jacques Le Roux]

Hi James,

I trust a Jira fits

Thanks

Jacques

Le 04/05/2020 à 14:54, James Yong a écrit :

Hi all,

Current Gradle version used in OFBiz trunk is 5.0.
Propose to update to Gradle 6.3 which is the current stable version.

Gradle 6.3 requires groovy 2.5.10., but Groovy version used in OFBiz trunk is 
2.5.4
Suggest to upgrade Groovy to 2.5.11 which is the current stable version.

For Gradle upgrade, I run:
./gradlew wrapper --gradle-version=6.3 --distribution-type=bin

For Groovy upgrade, I updated the build.gradle with the new Groovy version.

So far, no issue encountered with the upgrades on my side.

Let me know if any concerns.
Plan to create JIRA issue for the upgrades by next week.

Regards,
James

Upgrade Gradle and Groovy

[James Yong]

Hi all,

Current Gradle version used in OFBiz trunk is 5.0.
Propose to update to Gradle 6.3 which is the current stable version.

Gradle 6.3 requires groovy 2.5.10., but Groovy version used in OFBiz trunk is 
2.5.4
Suggest to upgrade Groovy to 2.5.11 which is the current stable version.

For Gradle upgrade, I run:
./gradlew wrapper --gradle-version=6.3 --distribution-type=bin

For Groovy upgrade, I updated the build.gradle with the new Groovy version.

So far, no issue encountered with the upgrades on my side.

Let me know if any concerns.
Plan to create JIRA issue for the upgrades by next week.

Regards,
James

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

[Suraj Khurana]

Thanks Jacques for taking care of it.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

On Mon, Apr 27, 2020 at 9:43 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I don't remember if it was intentional, I think I missed them and will add
> them "right now"
>
> Thanks
>
> Le 27/04/2020 à 12:36, Suraj Khurana a écrit :
> > I meant, in the XML version we were sending note (Test note) and comments
> > (Test Comments) as well in serviceCtx, but in the converted version we
> are
> > not sending these fields.
> >
> > Tests will pass for sure, as they are not mandatory to send.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Senior Technical Consultant
> >
> >
> > On Mon, Apr 27, 2020 at 2:52 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Hi Suraj,
> >>
> >> If you mean that there is no explanation but "Tests pass", as it's Svn
> we
> >> can still amend it, what would you suggest?
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >> Le 27/04/2020 à 08:47, Suraj Khurana a écrit :
> >>> Hello Jacques,
> >>>
> >>> I think we missed the note, comments field during conversion in this
> >> commit.
> >>> Is it intentional, or am I missing something?
> >>>
> >>> --
> >>> Best Regards,
> >>> Suraj Khurana
> >>> Senior Technical Consultant
> >>>
> >>> On Thu, Oct 3, 2019 at 5:00 PM  wrote:
> >>>
> >>>> Author: jleroux
> >>>> Date: Thu Oct  3 11:30:28 2019
> >>>> New Revision: 1867927
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1867927&view=rev
> >>>> Log:
> >>>> Improved: Convert testSendOrderChangeNotification to Groovy
> >>>> (OFBIZ-11233)
> >>>>
> >>>> Tests pass
> >>>>
> >>>> Modified:
> >>>>
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >>>> Modified:
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >>>> URL:
> >>>>
> >>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml?rev=1867927&r1=1867926&r2=1867927&view=diff
> >>>>
> >>
> ==
> >>>> ---
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >>>> (original)
> >>>> +++
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >>>> Thu Oct  3 11:30:28 2019
> >>>> @@ -154,23 +154,4 @@ under the License.
> >>>>
> >>>>
> >>>>
> >>>> -
> >>>> - >>>> short-description="Sends order change confirmation mail"
> >>>> login-required="false">
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> - >>>> in-map-name="serviceCtx">
> >>>> -
> >>>> -
> >>>> -
> >>>> -
> >>>> - >> field="serviceResult.emailType"
> >>>> value="PRDS_ODR_CHANGE" />
> >>>> -
> >>>> -
> >>>> -
> >>>>
> >>>> \ No newline at end of file
> >>>>
> >>>> Modified:
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >>>> URL:
> >>>>
> >>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy?rev=1867927&r1=1867926&r2=1867927&view=diff
> >>>>
> >>
> ==
> >>>> ---
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >>>> (original)
> >>>> +++
> >>>>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >>>> Thu Oct  3 11:30:28 2019
> >>>> @@ -212,4 +212,17 @@ class OrderTests extends OFBizTestCase {
> >>>>Map serviceResult =
> >>>> dispatcher.runSync('associatedRequirementWithRequestItem', serviceCtx)
> >>>>assert ServiceUtil.isSuccess(serviceResult)
> >>>>}
> >>>> +
> >>>> +void testSendOrderChangeNotification() {
> >>>> +Map serviceCtx = [
> >>>> +  orderId: 'TEST_DEMO10090',
> >>>> +  sendTo: 'test_em...@example.com',
> >>>> +  userLogin:
> >>>> EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
> >>>> 'system').cache().queryOne()
> >>>> +]
> >>>> +Map serviceResult =
> >>>> dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
> >>>> +assert ServiceUtil.isSuccess(serviceResult)
> >>>> +assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> >>>> +}
> >>>> +
> >>>> +
> >>>>}
> >>>>
> >>>>
> >>>>
>

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

[Jacques Le Roux]

I don't remember if it was intentional, I think I missed them and will add them 
"right now"

Thanks

Le 27/04/2020 à 12:36, Suraj Khurana a écrit :

I meant, in the XML version we were sending note (Test note) and comments
(Test Comments) as well in serviceCtx, but in the converted version we are
not sending these fields.

Tests will pass for sure, as they are not mandatory to send.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Mon, Apr 27, 2020 at 2:52 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

If you mean that there is no explanation but "Tests pass", as it's Svn we
can still amend it, what would you suggest?

Thanks

Jacques

Le 27/04/2020 à 08:47, Suraj Khurana a écrit :

Hello Jacques,

I think we missed the note, comments field during conversion in this

commit.

Is it intentional, or am I missing something?

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

On Thu, Oct 3, 2019 at 5:00 PM  wrote:


Author: jleroux
Date: Thu Oct  3 11:30:28 2019
New Revision: 1867927

URL: http://svn.apache.org/viewvc?rev=1867927&view=rev
Log:
Improved: Convert testSendOrderChangeNotification to Groovy
(OFBIZ-11233)

Tests pass

Modified:



ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml



ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

Modified:


ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml

URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml?rev=1867927&r1=1867926&r2=1867927&view=diff



==

---


ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml

(original)
+++


ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml

Thu Oct  3 11:30:28 2019
@@ -154,23 +154,4 @@ under the License.
   
   
   
-
-
-
-
-
-
-
-
-
-
newtest_em...@example.com

"/>
-
-
-
-
-
-
field="serviceResult.emailType"

value="PRDS_ODR_CHANGE" />
-
-
-
   
\ No newline at end of file

Modified:


ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy?rev=1867927&r1=1867926&r2=1867927&view=diff



======

---


ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

(original)
+++


ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

Thu Oct  3 11:30:28 2019
@@ -212,4 +212,17 @@ class OrderTests extends OFBizTestCase {
   Map serviceResult =
dispatcher.runSync('associatedRequirementWithRequestItem', serviceCtx)
   assert ServiceUtil.isSuccess(serviceResult)
   }
+
+void testSendOrderChangeNotification() {
+Map serviceCtx = [
+  orderId: 'TEST_DEMO10090',
+  sendTo: 'test_em...@example.com',
+  userLogin:
EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
'system').cache().queryOne()
+]
+Map serviceResult =
dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
+assert ServiceUtil.isSuccess(serviceResult)
+assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
+}
+
+
   }

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

[Suraj Khurana]

I meant, in the XML version we were sending note (Test note) and comments
(Test Comments) as well in serviceCtx, but in the converted version we are
not sending these fields.

Tests will pass for sure, as they are not mandatory to send.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Mon, Apr 27, 2020 at 2:52 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Suraj,
>
> If you mean that there is no explanation but "Tests pass", as it's Svn we
> can still amend it, what would you suggest?
>
> Thanks
>
> Jacques
>
> Le 27/04/2020 à 08:47, Suraj Khurana a écrit :
> > Hello Jacques,
> >
> > I think we missed the note, comments field during conversion in this
> commit.
> > Is it intentional, or am I missing something?
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Senior Technical Consultant
> >
> > On Thu, Oct 3, 2019 at 5:00 PM  wrote:
> >
> >> Author: jleroux
> >> Date: Thu Oct  3 11:30:28 2019
> >> New Revision: 1867927
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1867927&view=rev
> >> Log:
> >> Improved: Convert testSendOrderChangeNotification to Groovy
> >> (OFBIZ-11233)
> >>
> >> Tests pass
> >>
> >> Modified:
> >>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >>
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >>
> >> Modified:
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >> URL:
> >>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml?rev=1867927&r1=1867926&r2=1867927&view=diff
> >>
> >>
> ==
> >> ---
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >> (original)
> >> +++
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> >> Thu Oct  3 11:30:28 2019
> >> @@ -154,23 +154,4 @@ under the License.
> >>   
> >>   
> >>   
> >> -
> >> - >> short-description="Sends order change confirmation mail"
> >> login-required="false">
> >> -
> >> -
> >> -
> >> -
> >> -    
> >> -
> >> -
> >> -
> >> - >> in-map-name="serviceCtx">
> >> -
> >> -
> >> -
> >> -
> >> - field="serviceResult.emailType"
> >> value="PRDS_ODR_CHANGE" />
> >> -
> >> -
> >> -
> >>   
> >> \ No newline at end of file
> >>
> >> Modified:
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >> URL:
> >>
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy?rev=1867927&r1=1867926&r2=1867927&view=diff
> >>
> >>
> ==
> >> ---
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >> (original)
> >> +++
> >>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> >> Thu Oct  3 11:30:28 2019
> >> @@ -212,4 +212,17 @@ class OrderTests extends OFBizTestCase {
> >>   Map serviceResult =
> >> dispatcher.runSync('associatedRequirementWithRequestItem', serviceCtx)
> >>   assert ServiceUtil.isSuccess(serviceResult)
> >>   }
> >> +
> >> +void testSendOrderChangeNotification() {
> >> +Map serviceCtx = [
> >> +  orderId: 'TEST_DEMO10090',
> >> +  sendTo: 'test_em...@example.com',
> >> +  userLogin:
> >> EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
> >> 'system').cache().queryOne()
> >> +]
> >> +Map serviceResult =
> >> dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
> >> +assert ServiceUtil.isSuccess(serviceResult)
> >> +assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> >> +}
> >> +
> >> +
> >>   }
> >>
> >>
> >>
>

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

[Jacques Le Roux]

Hi Suraj,

If you mean that there is no explanation but "Tests pass", as it's Svn we can 
still amend it, what would you suggest?

Thanks

Jacques

Le 27/04/2020 à 08:47, Suraj Khurana a écrit :

Hello Jacques,

I think we missed the note, comments field during conversion in this commit.
Is it intentional, or am I missing something?

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

On Thu, Oct 3, 2019 at 5:00 PM  wrote:


Author: jleroux
Date: Thu Oct  3 11:30:28 2019
New Revision: 1867927

URL: http://svn.apache.org/viewvc?rev=1867927&view=rev
Log:
Improved: Convert testSendOrderChangeNotification to Groovy
(OFBIZ-11233)

Tests pass

Modified:

ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml

ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

Modified:
ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml?rev=1867927&r1=1867926&r2=1867927&view=diff

==
---
ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
(original)
+++
ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
Thu Oct  3 11:30:28 2019
@@ -154,23 +154,4 @@ under the License.
  
  
  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
  
\ No newline at end of file

Modified:
ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy?rev=1867927&r1=1867926&r2=1867927&view=diff

==
---
ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
(original)
+++
ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
Thu Oct  3 11:30:28 2019
@@ -212,4 +212,17 @@ class OrderTests extends OFBizTestCase {
  Map serviceResult =
dispatcher.runSync('associatedRequirementWithRequestItem', serviceCtx)
  assert ServiceUtil.isSuccess(serviceResult)
  }
+
+void testSendOrderChangeNotification() {
+Map serviceCtx = [
+  orderId: 'TEST_DEMO10090',
+  sendTo: 'test_em...@example.com',
+  userLogin:
EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
'system').cache().queryOne()
+]
+Map serviceResult =
dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
+assert ServiceUtil.isSuccess(serviceResult)
+assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
+}
+
+
  }

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

[Suraj Khurana]

Hello Jacques,

I think we missed the note, comments field during conversion in this commit.
Is it intentional, or am I missing something?

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

On Thu, Oct 3, 2019 at 5:00 PM  wrote:

> Author: jleroux
> Date: Thu Oct  3 11:30:28 2019
> New Revision: 1867927
>
> URL: http://svn.apache.org/viewvc?rev=1867927&view=rev
> Log:
> Improved: Convert testSendOrderChangeNotification to Groovy
> (OFBIZ-11233)
>
> Tests pass
>
> Modified:
>
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
>
> Modified:
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml?rev=1867927&r1=1867926&r2=1867927&view=diff
>
> ==
> ---
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml
> Thu Oct  3 11:30:28 2019
> @@ -154,23 +154,4 @@ under the License.
>  
>  
>  
> -
> - short-description="Sends order change confirmation mail"
> login-required="false">
> -
> -
> -
> -
> -
> -
> -
> -
> - in-map-name="serviceCtx">
> -
> -
> -
> -    
> - value="PRDS_ODR_CHANGE" />
> -
> -
> -
>  
> \ No newline at end of file
>
> Modified:
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy?rev=1867927&r1=1867926&r2=1867927&view=diff
>
> ======
> ---
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
> Thu Oct  3 11:30:28 2019
> @@ -212,4 +212,17 @@ class OrderTests extends OFBizTestCase {
>  Map serviceResult =
> dispatcher.runSync('associatedRequirementWithRequestItem', serviceCtx)
>  assert ServiceUtil.isSuccess(serviceResult)
>  }
> +
> +void testSendOrderChangeNotification() {
> +Map serviceCtx = [
> +  orderId: 'TEST_DEMO10090',
> +  sendTo: 'test_em...@example.com',
> +  userLogin:
> EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
> 'system').cache().queryOne()
> +]
> +Map serviceResult =
> dispatcher.runSync('sendOrderChangeNotification', serviceCtx)
> +assert ServiceUtil.isSuccess(serviceResult)
> +assert serviceResult.emailType.equals("PRDS_ODR_CHANGE")
> +}
> +
> +
>  }
>
>
>

Re: Groovy Migration : createRequirementFromItemATP

[Jacques Le Roux]

Le 07/03/2020 à 10:42, Jacopo Cappellato a écrit :

On Fri, Mar 6, 2020 at 7:31 PM Pierre Smits  wrote:


Hi Gil,

If that other function ( createATPRequirementsForOrder service) has been in
play since 2007, we can, i would say safely, assume that the
createRequirementFromItemATP function/service can be removed from the
codebase immediately and port its removal to the 18.11 branch. No need to
slate it deprecated and leave it in and forgotten.


+1

Jacopo


+1, also with all related to createRequirementFromItemATP string (labels & test)

Thanks

Jacques

Re: Groovy Migration : createRequirementFromItemATP

[Jacopo Cappellato]

On Fri, Mar 6, 2020 at 7:31 PM Pierre Smits  wrote:

> Hi Gil,
>
> If that other function ( createATPRequirementsForOrder service) has been in
> play since 2007, we can, i would say safely, assume that the
> createRequirementFromItemATP function/service can be removed from the
> codebase immediately and port its removal to the 18.11 branch. No need to
> slate it deprecated and leave it in and forgotten.
>

+1

Jacopo

>
>

Re: Groovy Migration : createRequirementFromItemATP

[Pierre Smits]

Hi Gil,

If that other function ( createATPRequirementsForOrder service) has been in
play since 2007, we can, i would say safely, assume that the
createRequirementFromItemATP function/service can be removed from the
codebase immediately and port its removal to the 18.11 branch. No need to
slate it deprecated and leave it in and forgotten.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Fri, Mar 6, 2020 at 6:04 PM Gil Portenseigne 
wrote:

> Hello !
>
> While migrating createRequirementFromItemATP, i stumbled upon a comment
> from David Jones :
> > NOTE DEJ20090902: this service is not called
> > anywhere, instead the createATPRequirementsForOrder service (written in
> > Java) is called; why this is the case I don't know... -->
>
> I investigate a bit and find out the commit
>
> https://github.com/apache/ofbiz-framework/commit/edc1c0398f77157f590ad99d52e90fc29e251190
> That seems to refactor the service.
>
> As createRequirementFromItemATP minilang service seems not used in
> project (outside one integration test), should we not deprecated it in
> next release (18.12) and remove it in trunk ?
>
> WDYT ?
>
> Regards,
>
> Gil
>

Groovy Migration : createRequirementFromItemATP

[Gil Portenseigne]

Hello !

While migrating createRequirementFromItemATP, i stumbled upon a comment
from David Jones : 
> NOTE DEJ20090902: this service is not called
> anywhere, instead the createATPRequirementsForOrder service (written in
> Java) is called; why this is the case I don't know... -->

I investigate a bit and find out the commit
https://github.com/apache/ofbiz-framework/commit/edc1c0398f77157f590ad99d52e90fc29e251190
That seems to refactor the service.

As createRequirementFromItemATP minilang service seems not used in
project (outside one integration test), should we not deprecated it in
next release (18.12) and remove it in trunk ?

WDYT ?

Regards,

Gil


signature.asc
Description: PGP signature

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

[Jacques Le Roux]

Le 05/03/2020 à 14:26, Nicolas Malin a écrit :

Kelvin it's the nickname for Elvis ?

Ah(?), OK

Jacques

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

[Nicolas Malin]

^^ Kelvin syntax.

Kelvin it's the nickname for Elvis ?

Nicolas

On 28/02/2020 21:08, Jacques Le Roux wrote:
> Le 28/02/2020 à 17:49, ASF subversion and git services (Jira) a écrit :
>> use kelvin syntax
>
> Hi Nicolas, Gil,
>
> Could you explain why you refer to Kelvin Syntax? 


pEpkey.asc
Description: application/pgp-keys

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

[Jacques Le Roux]

Le 28/02/2020 à 17:49, ASF subversion and git services (Jira) a écrit :

use kelvin syntax


Hi Nicolas, Gil,

Could you explain why you refer to Kelvin Syntax?

TIA

Jacques

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)

[Michael Brohl]

Hi Nicolas,

great, thanks for reviewing and improving the code!

Please go ahead and commit,

thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.02.20 um 16:22 schrieb Nicolas Malin:

Michael, I have lot of improvement to share with your commit (groovy
syntax, code simplification)

Do you prefer keep the hand, or I commit directly ?

You can find some diff on my starting work here  [1]

Cheers,

Nicolas

[1]
https://github.com/nmalin/ApacheOFBiz/compare/ProductService.groovy?expand=1

On 21/02/2020 17:51, mbr...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

mbrohl pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new e0a26fc  Improved: Convert ProductServices.xml mini lang to groovy 
(OFBIZ-10231)
e0a26fc is described below

commit e0a26fce43eec7c84d87c0d5055ff0a87f2af796
Author: Michael Brohl 
AuthorDate: Fri Feb 21 16:59:37 2020 +0100

 Improved: Convert ProductServices.xml mini lang to groovy
 (OFBIZ-10231)
 
 Thanks Dennis Balkir for reporting and Sebastian Berg for the implementation.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)

[Nicolas Malin]

Michael, I have lot of improvement to share with your commit (groovy
syntax, code simplification)

Do you prefer keep the hand, or I commit directly ?

You can find some diff on my starting work here  [1]

Cheers,

Nicolas

[1]
https://github.com/nmalin/ApacheOFBiz/compare/ProductService.groovy?expand=1

On 21/02/2020 17:51, mbr...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> mbrohl pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>  new e0a26fc  Improved: Convert ProductServices.xml mini lang to groovy 
> (OFBIZ-10231)
> e0a26fc is described below
>
> commit e0a26fce43eec7c84d87c0d5055ff0a87f2af796
> Author: Michael Brohl 
> AuthorDate: Fri Feb 21 16:59:37 2020 +0100
>
> Improved: Convert ProductServices.xml mini lang to groovy
> (OFBIZ-10231)
> 
> Thanks Dennis Balkir for reporting and Sebastian Berg for the 
> implementation.
> ---
>  .../product/product/ProductServices.groovy | 1095 
> 
>  .../minilang/product/product/ProductServices.xml   | 1051 ---
>  applications/product/servicedef/services.xml   |  112 +-
>  3 files changed, 1151 insertions(+), 1107 deletions(-)
>
> diff --git 
> a/applications/product/groovyScripts/product/product/ProductServices.groovy 
> b/applications/product/groovyScripts/product/product/ProductServices.groovy
> new file mode 100644
> index 000..b4be894
> --- /dev/null
> +++ 
> b/applications/product/groovyScripts/product/product/ProductServices.groovy
> @@ -0,0 +1,1095 @@
> +/*
> +  * Licensed to the Apache Software Foundation (ASF) under one
> +  * or more contributor license agreements.  See the NOTICE file
> +  * distributed with this work for additional information
> +  * regarding copyright ownership.  The ASF licenses this file
> +  * to you under the Apache License, Version 2.0 (the
> +  * "License"); you may not use this file except in compliance
> +  * with the License.  You may obtain a copy of the License at
> +  *
> +  * http://www.apache.org/licenses/LICENSE-2.0
> +  *
> +  * Unless required by applicable law or agreed to in writing,
> +  * software distributed under the License is distributed on an
> +  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +  * KIND, either express or implied.  See the License for the
> +  * specific language governing permissions and limitations
> +  * under the License.
> +  */
> +
> +
> +import java.sql.Timestamp
> +
> +import org.apache.ofbiz.base.util.UtilDateTime
> +import org.apache.ofbiz.base.util.UtilProperties
> +import org.apache.ofbiz.base.util.UtilValidate
> +import org.apache.ofbiz.entity.GenericValue
> +import org.apache.ofbiz.entity.serialize.XmlSerializer
> +import org.apache.ofbiz.entity.util.EntityUtil
> +import org.apache.ofbiz.product.product.KeywordIndex
> +import org.apache.ofbiz.product.product.ProductWorker
> +import org.apache.ofbiz.service.ServiceUtil
> +
> +
> +
> + module = "ProductServices.groovy" // this is used for logging
> +
> + /**
> +  * Create a Product
> +  */
> + def createProduct() {
> +Map result = success()
> +if (!(security.hasEntityPermission("CATALOG", "_CREATE", 
> parameters.userLogin)
> +|| security.hasEntityPermission("CATALOG_ROLE", "_CREATE", 
> parameters.userLogin))) {
> +return error(UtilProperties.getMessage("ProductUiLabels", 
> "ProductCatalogCreatePermissionError", parameters.locale))
> +}
> +
> +GenericValue newEntity = makeValue("Product")
> +newEntity.setNonPKFields(parameters)
> +
> +newEntity.productId = parameters.productId
> +
> +if (UtilValidate.isEmpty(newEntity.productId)) {
> +newEntity.productId = delegator.getNextSeqId("Product")
> +} else {
> +String errorMessage = 
> UtilValidate.checkValidDatabaseId(newEntity.productId)
> +if(errorMessage != null) {
> +logError(errorMessage)
> +return error(errorMessage)
> +}
> +GenericValue dummyProduct = findOne("Product", ["productId": 
> parameters.productId], false)
> +if (UtilValidate.isNotEmpty(dummyProduct)) {
> + errorMessage = UtilProperties.getMessage("CommonErrorUiLabels", 
> CommonErrorDuplicateKey, parameters.locale)
> +logError(errorMessage)
> +return error(errorMessage)
> +}
> +}
> +result.productId = newEntit

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

[Jacques Le Roux]

Right,

Unfortunately we are not able to do that:

https://bigbrassband.com/git-integration-for-jira/documentation/linking-git-commits-to-jira-issues.html#manually_linkcommits

I then thought we could use "git notes" if we could find a way to incorporate 
git notes into releases notes.
But I found nothing googling for <> and 
variations

Too bad :/

Jacques

Le 08/02/2020 à 12:11, Pierre Smits a écrit :

Rewriting commit history is a NONO

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sat, Feb 8, 2020 at 11:29 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Never too late and anybody can do it...

Jacques

Le 06/02/2020 à 13:12, Pierre Smits a écrit :

It is a pity that the commit-message of this bug fixed does not

reference a

ticket. Now it will not show up in release note(s) when generated from

JIRA.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Thu, Feb 6, 2020 at 1:04 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

nmalin pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git


The following commit(s) were added to refs/heads/release18.12 by this

push:

   new 6296ab4  Fixed: Error when initialize billFromParty from

groovy

context in loadSalesOrderItemFact service
6296ab4 is described below

commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71
Author: Nicolas Malin 
AuthorDate: Thu Feb 6 13:03:18 2020 +0100

  Fixed: Error when initialize billFromParty from groovy context in
loadSalesOrderItemFact service

  After the conversion from bsh to groovy, the script that resolve
  billFromParty need to propage the value on context Map to be

available

  on minilang context
---
   bi/minilang/FactServices.xml | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bi/minilang/FactServices.xml b/bi/minilang/FactServices.xml
index 408b93c..13a72be 100644
--- a/bi/minilang/FactServices.xml
+++ b/bi/minilang/FactServices.xml
@@ -358,7 +358,7 @@ under the License.
   import org.apache.ofbiz.order.order.OrderReadHelper

   orderReadHelper = new OrderReadHelper(orderHeader)
-billFromParty = orderReadHelper.getBillFromParty()
+context.billFromParty =

orderReadHelper.getBillFromParty()

   
   
   

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

[Pierre Smits]

Rewriting commit history is a NONO

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sat, Feb 8, 2020 at 11:29 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Never too late and anybody can do it...
>
> Jacques
>
> Le 06/02/2020 à 13:12, Pierre Smits a écrit :
> > It is a pity that the commit-message of this bug fixed does not
> reference a
> > ticket. Now it will not show up in release note(s) when generated from
> JIRA.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Thu, Feb 6, 2020 at 1:04 PM  wrote:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> nmalin pushed a commit to branch release18.12
> >> in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/release18.12 by this
> push:
> >>   new 6296ab4  Fixed: Error when initialize billFromParty from
> groovy
> >> context in loadSalesOrderItemFact service
> >> 6296ab4 is described below
> >>
> >> commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71
> >> Author: Nicolas Malin 
> >> AuthorDate: Thu Feb 6 13:03:18 2020 +0100
> >>
> >>  Fixed: Error when initialize billFromParty from groovy context in
> >> loadSalesOrderItemFact service
> >>
> >>  After the conversion from bsh to groovy, the script that resolve
> >>  billFromParty need to propage the value on context Map to be
> available
> >>  on minilang context
> >> ---
> >>   bi/minilang/FactServices.xml | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/bi/minilang/FactServices.xml b/bi/minilang/FactServices.xml
> >> index 408b93c..13a72be 100644
> >> --- a/bi/minilang/FactServices.xml
> >> +++ b/bi/minilang/FactServices.xml
> >> @@ -358,7 +358,7 @@ under the License.
> >>   import org.apache.ofbiz.order.order.OrderReadHelper
> >>
> >>   orderReadHelper = new OrderReadHelper(orderHeader)
> >> -billFromParty = orderReadHelper.getBillFromParty()
> >> +context.billFromParty =
> orderReadHelper.getBillFromParty()
> >>   
> >>>> field="partyAccountingPreferencesCallMap.organizationPartyId"
> >> from-field="billFromParty.partyId"/>
> >>>> in-map-name="partyAccountingPreferencesCallMap">
> >>
> >>
>

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

[Jacques Le Roux]

Never too late and anybody can do it...

Jacques

Le 06/02/2020 à 13:12, Pierre Smits a écrit :

It is a pity that the commit-message of this bug fixed does not reference a
ticket. Now it will not show up in release note(s) when generated from JIRA.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Thu, Feb 6, 2020 at 1:04 PM  wrote:


This is an automated email from the ASF dual-hosted git repository.

nmalin pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git


The following commit(s) were added to refs/heads/release18.12 by this push:
  new 6296ab4  Fixed: Error when initialize billFromParty from groovy
context in loadSalesOrderItemFact service
6296ab4 is described below

commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71
Author: Nicolas Malin 
AuthorDate: Thu Feb 6 13:03:18 2020 +0100

 Fixed: Error when initialize billFromParty from groovy context in
loadSalesOrderItemFact service

 After the conversion from bsh to groovy, the script that resolve
 billFromParty need to propage the value on context Map to be available
 on minilang context
---
  bi/minilang/FactServices.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bi/minilang/FactServices.xml b/bi/minilang/FactServices.xml
index 408b93c..13a72be 100644
--- a/bi/minilang/FactServices.xml
+++ b/bi/minilang/FactServices.xml
@@ -358,7 +358,7 @@ under the License.
  import org.apache.ofbiz.order.order.OrderReadHelper

  orderReadHelper = new OrderReadHelper(orderHeader)
-billFromParty = orderReadHelper.getBillFromParty()
+context.billFromParty = orderReadHelper.getBillFromParty()
  
  
  

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

[Pierre Smits]

It is a pity that the commit-message of this bug fixed does not reference a
ticket. Now it will not show up in release note(s) when generated from JIRA.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Thu, Feb 6, 2020 at 1:04 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> nmalin pushed a commit to branch release18.12
> in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git
>
>
> The following commit(s) were added to refs/heads/release18.12 by this push:
>  new 6296ab4  Fixed: Error when initialize billFromParty from groovy
> context in loadSalesOrderItemFact service
> 6296ab4 is described below
>
> commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71
> Author: Nicolas Malin 
> AuthorDate: Thu Feb 6 13:03:18 2020 +0100
>
> Fixed: Error when initialize billFromParty from groovy context in
> loadSalesOrderItemFact service
>
> After the conversion from bsh to groovy, the script that resolve
> billFromParty need to propage the value on context Map to be available
> on minilang context
> ---
>  bi/minilang/FactServices.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bi/minilang/FactServices.xml b/bi/minilang/FactServices.xml
> index 408b93c..13a72be 100644
> --- a/bi/minilang/FactServices.xml
> +++ b/bi/minilang/FactServices.xml
> @@ -358,7 +358,7 @@ under the License.
>  import org.apache.ofbiz.order.order.OrderReadHelper
>
>  orderReadHelper = new OrderReadHelper(orderHeader)
> -billFromParty = orderReadHelper.getBillFromParty()
> +context.billFromParty = orderReadHelper.getBillFromParty()
>  
>   field="partyAccountingPreferencesCallMap.organizationPartyId"
> from-field="billFromParty.partyId"/>
>   in-map-name="partyAccountingPreferencesCallMap">
>
>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits]

08*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
> > wrote:
> >
> >> Hi Jacques,
> >>
> >> just stumbled upon this topic again, inline...
> >>
> >> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> >>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> >>> OFBIZ-10205 and this thread, ie indeed mostly "move them to
> >>> src/main/groovy". That's enough for my need.
> >>>
> >>> Using @CompileStatic is out of my scope because I want to keep Groovy
> >>> scripts dynamic.
> >> I'd like to bring up this thead again and encourage everyone to read the
> >> mentioned article by David E. Jones:
> >>
> >>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
> >>
> >> We should be careful and act responsible when deciding certain
> >> principles and patterns. While it is of course more simple for
> >> developers to have it dynamic it might be a nightmare in real world
> >> projects with huge traffic. We have our experiences with this.
> >>
> >> We had this discussion in the aforementioned thread. One argument
> >> against is "premature optimization" which is a killer argument to end
> >> such discussions. Of course there will be perfomance metrics only if we
> >> would implement the two patterns and compare runtime in a relevant load
> >> scenario which is not achievable.
> >>
> >> One can very well rely on the experiences of others and make use of
> >> patterns to avoid problems in the later run. It would be real bad for
> >> the project if we do mass changes and ignore these experiences just to
> >> end up with users having serious production problems.
> >>
> >> So I ask everyone involved to act responsible and take these
> >> informations into account when changing the code base.
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >>
> >>
> >>
>
>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Michael Brohl]

+1, with a remark

We should do the development on a feature branch based on trunk (instead 
of a release branch) and constantly merge trunk into it. This would 
allow to develop very near to the ongoing developments in other areas 
and merge back easily once the feature branch gets accepted. It would 
also allow field tests using the feature branch with the latest feature set.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 02.02.20 um 16:21 schrieb Pierre Smits:

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
wrote:


Hi Jacques,

just stumbled upon this topic again, inline...

Am 20.09.19 um 17:39 schrieb Jacques Le Roux:

In a 1st time I intend to do only what I wrote in OFBIZ-10226,
OFBIZ-10205 and this thread, ie indeed mostly "move them to
src/main/groovy". That's enough for my need.

Using @CompileStatic is out of my scope because I want to keep Groovy
scripts dynamic.

I'd like to bring up this thead again and encourage everyone to read the
mentioned article by David E. Jones:

https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E

We should be careful and act responsible when deciding certain
principles and patterns. While it is of course more simple for
developers to have it dynamic it might be a nightmare in real world
projects with huge traffic. We have our experiences with this.

We had this discussion in the aforementioned thread. One argument
against is "premature optimization" which is a killer argument to end
such discussions. Of course there will be perfomance metrics only if we
would implement the two patterns and compare runtime in a relevant load
scenario which is not achievable.

One can very well rely on the experiences of others and make use of
patterns to avoid problems in the later run. It would be real bad for
the project if we do mass changes and ignore these experiences just to
end up with users having serious production problems.

So I ask everyone involved to act responsible and take these
informations into account when changing the code base.

Thanks,

Michael








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits]

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
wrote:

> Hi Jacques,
>
> just stumbled upon this topic again, inline...
>
> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> > In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> > OFBIZ-10205 and this thread, ie indeed mostly "move them to
> > src/main/groovy". That's enough for my need.
> >
> > Using @CompileStatic is out of my scope because I want to keep Groovy
> > scripts dynamic.
>
> I'd like to bring up this thead again and encourage everyone to read the
> mentioned article by David E. Jones:
>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>
> We should be careful and act responsible when deciding certain
> principles and patterns. While it is of course more simple for
> developers to have it dynamic it might be a nightmare in real world
> projects with huge traffic. We have our experiences with this.
>
> We had this discussion in the aforementioned thread. One argument
> against is "premature optimization" which is a killer argument to end
> such discussions. Of course there will be perfomance metrics only if we
> would implement the two patterns and compare runtime in a relevant load
> scenario which is not achievable.
>
> One can very well rely on the experiences of others and make use of
> patterns to avoid problems in the later run. It would be real bad for
> the project if we do mass changes and ignore these experiences just to
> end up with users having serious production problems.
>
> So I ask everyone involved to act responsible and take these
> informations into account when changing the code base.
>
> Thanks,
>
> Michael
>
>
>
>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Michael Brohl]

Hi Jacques,

just stumbled upon this topic again, inline...

Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
In a 1st time I intend to do only what I wrote in OFBIZ-10226, 
OFBIZ-10205 and this thread, ie indeed mostly "move them to 
src/main/groovy". That's enough for my need.


Using @CompileStatic is out of my scope because I want to keep Groovy 
scripts dynamic.


I'd like to bring up this thead again and encourage everyone to read the 
mentioned article by David E. Jones: 
https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E


We should be careful and act responsible when deciding certain 
principles and patterns. While it is of course more simple for 
developers to have it dynamic it might be a nightmare in real world 
projects with huge traffic. We have our experiences with this.


We had this discussion in the aforementioned thread. One argument 
against is "premature optimization" which is a killer argument to end 
such discussions. Of course there will be perfomance metrics only if we 
would implement the two patterns and compare runtime in a relevant load 
scenario which is not achievable.


One can very well rely on the experiences of others and make use of 
patterns to avoid problems in the later run. It would be real bad for 
the project if we do mass changes and ignore these experiences just to 
end up with users having serious production problems.


So I ask everyone involved to act responsible and take these 
informations into account when changing the code base.


Thanks,

Michael





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Upgrading Groovy 2.4.16 → 2.5.8

[Mathieu Lirzin]

Thanks Gil,

Committed in revision 1869136 (BTW I made a mistake by referencing
OFBIZ-11268 instead of OFBIZ-11263).

Gil Portenseigne  writes:

> I've test the upgrade and saw no issue, so +1.
>
> Gil
>
>
>
> Le 18:19 - dimanche 27 oct., Mathieu Lirzin a écrit :
>> Hello,
>> 
>> I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable
>> release on ‘trunk’.
>> 
>> I did not detect any issue with the upgrade so I intend to commit the
>> patch in the following days.  If you are aware of an issue please jump
>> in.
>> 
>> Thanks.
>> 
>> [1] https://issues.apache.org/jira/browse/OFBIZ-11263
>> 
>> -- 
>> Mathieu Lirzin
>> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Upgrading Groovy 2.4.16 → 2.5.8

[Gil Portenseigne]

Hello Mathieu,

I've test the upgrade and saw no issue, so +1.

Gil



Le 18:19 - dimanche 27 oct., Mathieu Lirzin a écrit :
> Hello,
> 
> I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable
> release on ‘trunk’.
> 
> I did not detect any issue with the upgrade so I intend to commit the
> patch in the following days.  If you are aware of an issue please jump
> in.
> 
> Thanks.
> 
> [1] https://issues.apache.org/jira/browse/OFBIZ-11263
> 
> -- 
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Upgrading Groovy 2.4.16 → 2.5.8

[Mathieu Lirzin]

Hello,

I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable
release on ‘trunk’.

I did not detect any issue with the upgrade so I intend to commit the
patch in the following days.  If you are aware of an issue please jump
in.

Thanks.

[1] https://issues.apache.org/jira/browse/OFBIZ-11263

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: svn commit: r1867666 - in /ofbiz/ofbiz-framework/trunk/applications: accounting/src/main/groovy/org/apache/ofbiz/accounting/ accounting/testdef/data/ order/src/main/groovy/org/apache/ofbiz/order/

[Aditya Sharma]

Hi Pawan,

Thanks for your efforts in this direction, it seems the commit message
should be something like this:

===
Improved: Added Unit test case
(OFBIZ-8936)(OFBIZ-8874)(OFBIZ-8873)(OFBIZ-8872)(OFBIZ-8871)(OFBIZ-8870)(OFBIZ-8866)

Added Unit test case for following services
- createSimpleTextContentForInvoice
- processWaitReplacementReturn
- processWaitReplacementReservedReturn
- processSubscriptionReturn
- processReplacementReturn
- processReplaceImmediatelyReturn
- processRefundOnlyReturn


Thanks, Deepak Nigam, Avnindra Sharma and Anushi Gupta for your
contribution.
===

See Example 3 with details and multiple Jira references
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template

Thanks & Regards,
Aditya Sharma

On Sat, Sep 28, 2019 at 5:38 PM  wrote:

> Author: pawan
> Date: Sat Sep 28 12:08:46 2019
> New Revision: 1867666
>
> URL: http://svn.apache.org/viewvc?rev=1867666&view=rev
> Log:
> Improved: Added Unit test case for following services
> - createSimpleTextContentForInvoice
> - processWaitReplacementReturn
> - processWaitReplacementReservedReturn
> - processSubscriptionReturn
> - processReplacementReturn
> - processReplaceImmediatelyReturn
> - processRefundOnlyReturn
>
> (OFBIZ-8936)(OFBIZ-8874)(OFBIZ-8873)(OFBIZ-8872)(OFBIZ-8871)(OFBIZ-8870)(OFBIZ-8866)
>
> Thanks, Deepak Nigam, Avnindra Sharma and Anushi Gupta for your
> contribution.
>
> Modified:
>
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/groovy/org/apache/ofbiz/accounting/AutoAcctgInvoiceTests.groovy
>
> ofbiz/ofbiz-framework/trunk/applications/accounting/testdef/data/AccountingTestsData.xml
>
> ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy
>
> Modified:
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/groovy/org/apache/ofbiz/accounting/AutoAcctgInvoiceTests.groovy
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/groovy/org/apache/ofbiz/accounting/AutoAcctgInvoiceTests.groovy?rev=1867666&r1=1867665&r2=1867666&view=diff
>
> ======
> ---
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/groovy/org/apache/ofbiz/accounting/AutoAcctgInvoiceTests.groovy
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/groovy/org/apache/ofbiz/accounting/AutoAcctgInvoiceTests.groovy
> Sat Sep 28 12:08:46 2019
> @@ -52,4 +52,30 @@ class AutoAcctgInvoiceTests extends OFBi
>
>  assert invoiceContent.contentId == serviceResult.contentId
>  }
> +void testCreateSimpleTextContentForInvoice() {
> +def userLogin = EntityQuery.use(delegator).from('UserLogin')
> +.where('userLoginId', 'system')
> +.cache()
> +.queryOne()
> +
> +Map serviceCtx = [
> +invoiceId: '1009',
> +contentId: '1001',
> +contentTypeId: 'DOCUMENT',
> +invoiceContentTypeId: 'COMMENTS',
> +text: 'Content for invoice # 1009',
> +fromDate: UtilDateTime.nowTimestamp(),
> +userLogin: userLogin
> +]
> +Map serviceResult =
> dispatcher.runSync('createSimpleTextContentForInvoice', serviceCtx)
> +assert ServiceUtil.isSuccess(serviceResult)
> +
> +GenericValue invoiceContent =
> EntityQuery.use(delegator).from('InvoiceContent')
> +.where('invoiceId', '1009',
> +'contentId', '1001',
> +'invoiceContentTypeId', 'DOCUMENT')
> +.queryFirst()
> +
> +assert invoiceContent != null
> +}
>  }
>
> Modified:
> ofbiz/ofbiz-framework/trunk/applications/accounting/testdef/data/AccountingTestsData.xml
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/testdef/data/AccountingTestsData.xml?rev=1867666&r1=1867665&r2=1867666&view=diff
>
> ==
> ---
> ofbiz/ofbiz-framework/trunk/applications/accounting/testdef/data/AccountingTestsData.xml
> (original)
> +++
> ofbiz/ofbiz-framework/trunk/applications/accounting/testdef/data/AccountingTestsData.xml
> Sat Sep 28 12:08:46 2019
> @@ -99,6 +99,8 @@ under the License.
>   statusId="INVOICE_IN_PROCESS" partyIdFrom="DEMO_COMPANY"
> partyId="DEMO_COMPANY1" invoiceDate="2016-11-03 00:00:00"/>
>  
&g

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Jacques Le Roux]

Hi Samuel,

For the moment I don't expect to change "`commponent://` url in xml (screen, 
service,...)", but that a good idea!

I suggest you create a Jira for that

Thanks

Jacques

Le 23/09/2019 à 10:31, Samuel a écrit :

Hello Jacques,

I think it is a really good idea: add more checks on our code!

The option to use `gradlew --continous classes` make me think about putting 
more things into jar (but this another discussion )

I still have one question: what about `commponent://` url in xml (screen, service,...) ? are you going to rewrite ComponentLocationResolver to load 
groovy from compiled `.class`


Samuel


On 16/09/2019 12:28, Jacques Le Roux wrote:

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker 
templates and Groovy Scripts.


We also know the advantages of compilation. But then I thought: why not have 
best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it like 
that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax 
or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.


I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as 
suggested Mathieu.


I see no disadvantages, do you? If nobody disagree with this idea, I'll create 
a Jira for that.

Feedback welcome, thanks

Jacques

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Samuel]

Hello Jacques,

I think it is a really good idea: add more checks on our code!

The option to use `gradlew --continous classes` make me think about 
putting more things into jar (but this another discussion )


I still have one question: what about `commponent://` url in xml 
(screen, service,...) ? are you going to rewrite 
ComponentLocationResolver to load groovy from compiled `.class`


Samuel


On 16/09/2019 12:28, Jacques Le Roux wrote:

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle 
sourceSets" I discussed with Mathieu and we had some ideas.


Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.


I was initially reluctant because I love to be able to change things on 
the fly. That's why I liked Minilang and still like widgets, Freemarker 
templates and Groovy Scripts.


We also know the advantages of compilation. But then I thought: why not 
have best of both Groovy worlds: compile and on the fly.


I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it 
like that. It will continuously build on any changes in Gradle sourcesets


So, if you modify a Groovy scripts while running an OFBiz instance, the 
changes will be reflected in the instance and you can check possible 
syntax or alike issues in the terminal running the continuous build. 
It's very fast since only changes have an impact on the build.


I'm sure there are other benefits to follow "the common convention of 
putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as 
suggested Mathieu.


I see no disadvantages, do you? If nobody disagree with this idea, I'll 
create a Jira for that.


Feedback welcome, thanks

Jacques

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Taher Alkhateeb]

I see, in this case I think it's a good idea to comply with
conventions. It's strange that while I was working in the beginnings
on gradle I remember the opposite suggestion happening "keep the
scripts where they are" is what I heard repeatedly. Anyway, if it is
just a matter of moving, then it's not that big of a deal.

I suggest to do that slowly and carefully though. It is quite possible
to break many scripts due to location references.

On Fri, Sep 20, 2019 at 6:40 PM Jacques Le Roux
 wrote:
>
> In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 
> and this thread, ie indeed mostly "move them to src/main/groovy". That's
> enough for my need.
>
> Using @CompileStatic is out of my scope because I want to keep Groovy scripts 
> dynamic.
>
> Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :
> > I'm not sure I understand the outcome from reading the JIRA and this
> > thread. What will happen exactly? Are you going to make groovy scripts
> > part of the call stack? Are you going to use @CompileStatic? Or are
> > you just going to move them to src/main/groovy?
> >
> > On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
> >  wrote:
> >> Thanks Paul, Gil, for your suggestions,
> >>
> >> I have created OFBIZ-11205 for that
> >>
> >> Jacques
> >>
> >> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> >>> Hi Devs,
> >>>
> >>> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle 
> >>> sourceSets" I discussed with Mathieu and we had some ideas.
> >>>
> >>> Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> >>> to/src/main/groovy/.
> >>>
> >>> I was initially reluctant because I love to be able to change things on 
> >>> the fly. That's why I liked Minilang and still like widgets, Freemarker
> >>> templates and Groovy Scripts.
> >>>
> >>> We also know the advantages of compilation. But then I thought: why not 
> >>> have best of both Groovy worlds: compile and on the fly.
> >>>
> >>> I tried and it works. So here is the (simple) plan:
> >>>
> >>> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> >>> 2. We add the necessary packages names
> >>> 3. Devs can then open "gradlew --continuous" in a terminal and let it 
> >>> like that. It will continuously build on any changes in Gradle sourcesets
> >>>
> >>> So, if you modify a Groovy scripts while running an OFBiz instance, the 
> >>> changes will be reflected in the instance and you can check possible 
> >>> syntax
> >>> or alike issues in the terminal running the continuous build. It's very 
> >>> fast since only changes have an impact on the build.
> >>>
> >>> I'm sure there are other benefits to follow "the common convention of 
> >>> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> >>> suggested Mathieu.
> >>>
> >>> I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> >>> create a Jira for that.
> >>>
> >>> Feedback welcome, thanks
> >>>
> >>> Jacques
> >>>
> >>>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Jacques Le Roux]

In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's 
enough for my need.


Using @CompileStatic is out of my scope because I want to keep Groovy scripts 
dynamic.

Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :

I'm not sure I understand the outcome from reading the JIRA and this
thread. What will happen exactly? Are you going to make groovy scripts
part of the call stack? Are you going to use @CompileStatic? Or are
you just going to move them to src/main/groovy?

On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
 wrote:

Thanks Paul, Gil, for your suggestions,

I have created OFBIZ-11205 for that

Jacques

Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the 
fly. That's why I liked Minilang and still like widgets, Freemarker
templates and Groovy Scripts.

We also know the advantages of compilation. But then I thought: why not have 
best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it like 
that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes 
will be reflected in the instance and you can check possible syntax
or alike issues in the terminal running the continuous build. It's very fast 
since only changes have an impact on the build.

I'm sure there are other benefits to follow "the common convention of putting groovy 
compiled sources in ${COMPONENT}/src/main/groovy.", as
suggested Mathieu.

I see no disadvantages, do you? If nobody disagree with this idea, I'll create 
a Jira for that.

Feedback welcome, thanks

Jacques

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Taher Alkhateeb]

I'm not sure I understand the outcome from reading the JIRA and this
thread. What will happen exactly? Are you going to make groovy scripts
part of the call stack? Are you going to use @CompileStatic? Or are
you just going to move them to src/main/groovy?

On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
 wrote:
>
> Thanks Paul, Gil, for your suggestions,
>
> I have created OFBIZ-11205 for that
>
> Jacques
>
> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> > Hi Devs,
> >
> > While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" 
> > I discussed with Mathieu and we had some ideas.
> >
> > Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> > to/src/main/groovy/.
> >
> > I was initially reluctant because I love to be able to change things on the 
> > fly. That's why I liked Minilang and still like widgets, Freemarker
> > templates and Groovy Scripts.
> >
> > We also know the advantages of compilation. But then I thought: why not 
> > have best of both Groovy worlds: compile and on the fly.
> >
> > I tried and it works. So here is the (simple) plan:
> >
> > 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> > 2. We add the necessary packages names
> > 3. Devs can then open "gradlew --continuous" in a terminal and let it like 
> > that. It will continuously build on any changes in Gradle sourcesets
> >
> > So, if you modify a Groovy scripts while running an OFBiz instance, the 
> > changes will be reflected in the instance and you can check possible syntax
> > or alike issues in the terminal running the continuous build. It's very 
> > fast since only changes have an impact on the build.
> >
> > I'm sure there are other benefits to follow "the common convention of 
> > putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> > suggested Mathieu.
> >
> > I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> > create a Jira for that.
> >
> > Feedback welcome, thanks
> >
> > Jacques
> >
> >

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Jacques Le Roux]

Thanks Paul, Gil, for your suggestions,

I have created OFBIZ-11205 for that

Jacques

Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker 
templates and Groovy Scripts.


We also know the advantages of compilation. But then I thought: why not have 
best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it like 
that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax 
or alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.


I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as 
suggested Mathieu.


I see no disadvantages, do you? If nobody disagree with this idea, I'll create 
a Jira for that.

Feedback welcome, thanks

Jacques

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Gil Portenseigne]

Hello Jacques,

I also discussed about it with Mathieu and i find it very interesting.

The main advantage I see is, beside compilation, the integration in your
IDE, that was not optimum, and the possibility to re-use methods from
these script migrated to explicit classes.

So +1

Gil


Le 12:28 - lundi 16 sept., Jacques Le Roux a écrit :
> Hi Devs,
> 
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
> discussed with Mathieu and we had some ideas.
> 
> Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> to/src/main/groovy/.
> 
> I was initially reluctant because I love to be able to change things on the
> fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
> 
> We also know the advantages of compilation. But then I thought: why not have 
> best of both Groovy worlds: compile and on the fly.
> 
> I tried and it works. So here is the (simple) plan:
> 
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like 
> that. It will continuously build on any changes in Gradle sourcesets
> 
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
> 
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
> 
> I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> create a Jira for that.
> 
> Feedback welcome, thanks
> 
> Jacques
> 

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Paul Foxworthy]

Thanks Jacques,

Yes, on the fly rebuild is very cool. This will encourage and accelerate
moving Java services to Groovy, I think.

Big +1 from me.

Cheers

Paul

On Mon, 16 Sep 2019 at 20:29, Jacques Le Roux 
wrote:

> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets"
> I discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/
> to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on
> the fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not
> have best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
>  1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
>  2. We add the necessary packages names
>  3. Devs can then open "gradlew --continuous" in a terminal and let it
> like that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or
> alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested
> Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll
> create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>
>

-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

[DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Jacques Le Roux]

Hi Devs,

While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
discussed with Mathieu and we had some ideas.

Mathieu suggested to move Groovy scripts from /groovyScripts/ 
to/src/main/groovy/.

I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker 
templates and Groovy Scripts.


We also know the advantages of compilation. But then I thought: why not have 
best of both Groovy worlds: compile and on the fly.

I tried and it works. So here is the (simple) plan:

1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
2. We add the necessary packages names
3. Devs can then open "gradlew --continuous" in a terminal and let it like 
that. It will continuously build on any changes in Gradle sourcesets

So, if you modify a Groovy scripts while running an OFBiz instance, the changes will be reflected in the instance and you can check possible syntax or 
alike issues in the terminal running the continuous build. It's very fast since only changes have an impact on the build.


I'm sure there are other benefits to follow "the common convention of putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as suggested 
Mathieu.


I see no disadvantages, do you? If nobody disagree with this idea, I'll create 
a Jira for that.

Feedback welcome, thanks

Jacques

Re: Using plain Groovy classes for services.

[Jacopo Cappellato]

Hi Mathieu,

On Wed, Nov 14, 2018 at 12:38 AM Mathieu Lirzin 
wrote:

>
> Basically what I have in mind, is to organize services in classes like
> what is done in Java with the same method signature:
>
>   (Map ⨯ Map) → Map
>
> where the maps parameters correspond respectively to the “dispatch
> context” and the “service input”.  The main difference with Java
> services is the possibility to write map and list literals, and avoid
> explicit typing with ‘def’.  Additionally it would be easy to provide a
> method for the dispatcher which could reads like the current ‘run’
> method of the DSL and provide the same semantics (throwing an exception
> upon failure).  Something like:
>
>   dispatcher.run service: "fooService" with: [...]
>

One of the most useful features of the DSL is that the userLogin object,
needed to perform authorization checks when a service is invoked, is
automatically retrieved from the "context" and passed to the service call
(similarly to what was happening in the legacy Minilang). The same is
happening for the "timeZone" and "locale" objects. This helps to keep the
code cleaner with more focus on the business rules and less on technical
details. I think we should consider these aspects in the new design.

Jacopo

Re: Code Improvement for Groovy

[Pawan Verma]

Thanks Scott,

I'll keep that in my mind when changing this. Thanks!

-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Thu, May 16, 2019 at 1:53 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Scott,
>
> Quite helpful!
>
> Jacques
>
> Le 16/05/2019 à 10:12, Scott Gray a écrit :
> > Hi Pawan
> >
> > Sounds good, just one point to be careful of:
> > maxRetry = 0
> > if (!maxRetry) {
> >   // Not set, use a default
> >   maxRetry = -1
> > }
> >
> > Because groovy evaluates zero to be false, it wouldn't be possible to set
> > maxRetry to zero.  So it's best not to use groovy truth for null-checks
> on
> > numbers in some cases.  I thought it was worth mentioning since there's a
> > higher risk of making this mistake when making changes in bulk.
> >
> > Regards
> > Scott
> >
> > On Thu, 16 May 2019 at 00:29, Pawan Verma  >
> > wrote:
> >
> >> Hello Devs,
> >>
> >> As we all know, Groovy is a powerful language with great built-in
> >> functions. Groovy Truth[1] is one of them, which is not used properly in
> >> our code base. We have used UtilValidate Class to validate arguments for
> >> Empty or NotEmpty, which can easily be done in groovy with built-in
> >> functionality.
> >>
> >> Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }
> >>
> >> Groovy Built-in Code: if (locations) { ... }
> >>
> >> IMO, We should use this Groovy Truth feature instead of UtilValidate
> Class.
> >> Please let me know your thoughts on this. Thanks!
> >> [1] - http://groovy-lang.org/semantics.html#Groovy-Truth
> >>
> >> --
> >> Kind Regards
> >> Pawan Verma
> >> Technical Consultant
> >> *HotWax Systems*
> >>
>

Re: Code Improvement for Groovy

[Jacques Le Roux]

Thanks Scott,

Quite helpful!

Jacques

Le 16/05/2019 à 10:12, Scott Gray a écrit :

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
  // Not set, use a default
  maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:


Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*

Re: Code Improvement for Groovy

[Scott Gray]

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
 // Not set, use a default
 maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:

> Hello Devs,
>
> As we all know, Groovy is a powerful language with great built-in
> functions. Groovy Truth[1] is one of them, which is not used properly in
> our code base. We have used UtilValidate Class to validate arguments for
> Empty or NotEmpty, which can easily be done in groovy with built-in
> functionality.
>
> Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }
>
> Groovy Built-in Code: if (locations) { ... }
>
> IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
> Please let me know your thoughts on this. Thanks!
> [1] - http://groovy-lang.org/semantics.html#Groovy-Truth
>
> --
> Kind Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
>

Re: Code Improvement for Groovy

[Rishi Solanki]

+1

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Wed, May 15, 2019 at 8:33 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pawan,
>
> Sure, we use that from start a lot. But some don't it seems. A Jira fits
> with me
>
> Le 15/05/2019 à 14:29, Pawan Verma a écrit :
> > Hello Devs,
> >
> > As we all know, Groovy is a powerful language with great built-in
> > functions. Groovy Truth[1] is one of them, which is not used properly in
> > our code base. We have used UtilValidate Class to validate arguments for
> > Empty or NotEmpty, which can easily be done in groovy with built-in
> > functionality.
> >
> > Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }
> >
> > Groovy Built-in Code: if (locations) { ... }
> >
> > IMO, We should use this Groovy Truth feature instead of UtilValidate
> Class.
> > Please let me know your thoughts on this. Thanks!
> > [1] - http://groovy-lang.org/semantics.html#Groovy-Truth
> >
> > --
> > Kind Regards
> > Pawan Verma
> > Technical Consultant
> > *HotWax Systems*
> >
>

Re: Code Improvement for Groovy

[Jacques Le Roux]

Hi Pawan,

Sure, we use that from start a lot. But some don't it seems. A Jira fits with me

Le 15/05/2019 à 14:29, Pawan Verma a écrit :

Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*

Code Improvement for Groovy

[Pawan Verma]

Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Gil Portenseigne]

Hello,

The difference with the documentation and Mathieu's example is the
presence of String concatenation. Here lies the performance improvment.

If there a simple String is used, the if is uneeded :)

Regards

Gil

Le 19:58 - mardi 11 déc., Taher Alkhateeb a écrit :
> The official documentation mentions that performance is hit [1] with metrics.
> 
> [1] 
> https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams
> On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin
>  wrote:
> >
> > He gets exactly the same performance results (1.08× ns/op) with either
> > of the following options:
> >
> >1) Debug.log("...")
> >2) if (Debug.isEnabled()) { Debug.log("...") }
> >3) Debug.log(() -> "...")
> >

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Taher Alkhateeb]

The official documentation mentions that performance is hit [1] with metrics.

[1] https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams
On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin
 wrote:
>
> Hello Michael,
>
> Michael Brohl  writes:
>
> > Yes, right, but it's certainly less costly than the direct execution
> > of Debug.logXxxx... And that's the point. You don't want to run these
> > statments thousands of times within a minute (in production systems),
> > which is the case in central functionality like the controller.
>
> According to Rémi Forax's numbers this assumption is *not* verified! [1]
>
> He gets exactly the same performance results (1.08× ns/op) with either
> of the following options:
>
>1) Debug.log("...")
>2) if (Debug.isEnabled()) { Debug.log("...") }
>3) Debug.log(() -> "...")
>
> > Who cares? Each improvement is a gain and if we only introduce these
> > conditions in the hotspot functionality, it's an improvement.
> >
> > It's not only black and white...
>
> I think that any claim of performance gain/loss must be backed by an
> actual measurement, and this has not been the case in this discussion.
>
> Personnally I care about the readability of the code and choosing the
> option 2 is not helping in that regard.
>
> [1] https://youtu.be/z5UkoLaW6ME?t=213
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Mathieu Lirzin]

Hello Michael,

Michael Brohl  writes:

> Yes, right, but it's certainly less costly than the direct execution
> of Debug.logXxxx... And that's the point. You don't want to run these
> statments thousands of times within a minute (in production systems),
> which is the case in central functionality like the controller.

According to Rémi Forax's numbers this assumption is *not* verified! [1]

He gets exactly the same performance results (1.08× ns/op) with either
of the following options:

   1) Debug.log("...")
   2) if (Debug.isEnabled()) { Debug.log("...") }
   3) Debug.log(() -> "...")

> Who cares? Each improvement is a gain and if we only introduce these
> conditions in the hotspot functionality, it's an improvement.
>
> It's not only black and white...

I think that any claim of performance gain/loss must be backed by an
actual measurement, and this has not been the case in this discussion.

Personnally I care about the readability of the code and choosing the
option 2 is not helping in that regard.

[1] https://youtu.be/z5UkoLaW6ME?t=213

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Jacques Le Roux]

Hi Michael,

Le 11/12/2018 à 15:57, Michael Brohl a écrit :

Am 11.12.18 um 13:42 schrieb Jacques Le Roux:

Because

1. The if condition has a cost (3 times more than nothing according to 
Mathieu's reference[1])


Yes, right, but it's certainly less costly than the direct execution of Debug.logXxxx... And that's the point. You don't want to run these statments 
thousands of times within a minute (in production systems), which is the case in central functionality like the controller.


You can only leave out the if conditions if you are sure that the correpsonding 
debug level is always on.

As I said earlier, this is not the case for verbose, debug and info on 
production systems.


I see no problems with that





2. and is not consistently used.


Who cares? Each improvement is a gain and if we only introduce these conditions 
in the hotspot functionality, it's an improvement.

It's not only black and white...


Yes you are right, custom projects can hopefully adapt and contribute.





3. Using "Beautiful Logger" could be a better solution: 
https://github.com/forax/beautiful_logger
   drawbacks:
 *   needs Java 11 to build. But will we use Java 8 forever? Can run with 
Java 8.
 * "put more pressure to the JITs so it may lengthen the time to steady state of 
an application."

[1] https://www.youtube.com/watch?v=z5UkoLaW6ME (French)


Although this seems interesting, it is fairly new with the first release early this year. I won't recommend to introduce it until it's field tested 
(in production).


*That's the most important point of this discussion*

I agree, but if nobody test it it will not fly soon ;)

Actually I'm not worried Rémi is very well know in the French and global Java 
community. And we need to use Java 11...

I  have created OFBIZ-10704 to not forget to check what embedding it in OFBiz 
would mean.

Thanks


Jacques




Thanks,
Michael




Jacques

Le 11/12/2018 à 12:15, Taher Alkhateeb a écrit :

We already agreed and decided to keep the if condition. I'm not sure
why this subject is being reopened.
On Mon, Dec 10, 2018 at 9:49 PM Jacques Le Roux
 wrote:
The question is quite simple. It's about always using or not the /if (Debug.levelOn()) {/ expression for the info and debug level as suggests 
Michael.


Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend for the 
reasons explained.

I think we all agree the /if/ /(Debug.verboseOn()) { /should always be used and 
enforced when missing.

I put all the details/arguments to easily refer to them if needed.

Also Mathieu suggested to Michael to have a look at "Beautiful Logger" because 
he is concerned by the logging performance. We could also have a look
at it, to see if it could be integrated OOTB.

HTH

Jacques

Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have another discussion following 
https://markmail.org/message/mplvusuqn7oshl4v

which was one year ago.

In OFBIZ-10697 I wrote:

  <  By default OOTB debug.properties sets all debug levels to be used but verbose. So there is no point checking other levels than verbose to 
see if

  they are used, they are anyway. So OOTB only checking verbose is needed. 
That's what developers need.

  Now you invoked production where a different debug.properties setting would be used. Sincerely I'd never, never, remove the other levels 
than
  verbose from a production setting (as it's OOTB). I'd even be quite reluctant to remove any of those levels from a production site 
running for

  years! *You never know what can happen*, and those debug levels are your 
only lifebelt in case of issues, small and big ones.

  That's my point, and that's why I see checking if a level is used as premature optimisation but for verbose. We need them anyway and IMO 
setting

  false for any but verbose in debug.properties in production would be conceited if 
not "suicidal" . But maybe you have use cases I ignore?

  Anway, I'll start a discussion in dev ML about this point. Like I said above and in OFBIZ-10448 
<https://issues.apache.org/jira/browse/OFBIZ-10448>:


  I'd be all for removing the 312 useless cases but not the "if 
(Debug.verboseOn())">>

To what Michael answered

  <>

I think Michael's point is perfectly valid. So I answered:

  <  OK then we need to see things otherwise and rather enforce the checks to these 2 levels at least in all the source (Java and Groovy). 
That's what

  I'll ask in the convo to come in dev ML.>>

So what are your opinion about that? Should we enforce as suggest Michael or 
should 

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Michael Brohl]

Hi Jacques,

inline...


Am 11.12.18 um 13:42 schrieb Jacques Le Roux:

Because

1. The if condition has a cost (3 times more than nothing according to 
Mathieu's reference[1])


Yes, right, but it's certainly less costly than the direct execution of 
Debug.logXxxx... And that's the point. You don't want to run these 
statments thousands of times within a minute (in production systems), 
which is the case in central functionality like the controller.


You can only leave out the if conditions if you are sure that the 
correpsonding debug level is always on.


As I said earlier, this is not the case for verbose, debug and info on 
production systems.



2. and is not consistently used.


Who cares? Each improvement is a gain and if we only introduce these 
conditions in the hotspot functionality, it's an improvement.


It's not only black and white...

3. Using "Beautiful Logger" could be a better solution: 
https://github.com/forax/beautiful_logger

   drawbacks:
 *   needs Java 11 to build. But will we use Java 8 forever? Can 
run with Java 8.
 * "put more pressure to the JITs so it may lengthen the time to 
steady state of an application."


[1] https://www.youtube.com/watch?v=z5UkoLaW6ME (French)


Although this seems interesting, it is fairly new with the first release 
early this year. I won't recommend to introduce it until it's field 
tested (in production).


Thanks,
Michael




Jacques

Le 11/12/2018 à 12:15, Taher Alkhateeb a écrit :

We already agreed and decided to keep the if condition. I'm not sure
why this subject is being reopened.
On Mon, Dec 10, 2018 at 9:49 PM Jacques Le Roux
 wrote:
The question is quite simple. It's about always using or not the /if 
(Debug.levelOn()) {/ expression for the info and debug level as 
suggests Michael.


Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend 
for the reasons explained.


I think we all agree the /if/ /(Debug.verboseOn()) { /should always 
be used and enforced when missing.


I put all the details/arguments to easily refer to them if needed.

Also Mathieu suggested to Michael to have a look at "Beautiful 
Logger" because he is concerned by the logging performance. We could 
also have a look

at it, to see if it could be integrated OOTB.

HTH

Jacques

Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time 
to have another discussion following 
https://markmail.org/message/mplvusuqn7oshl4v

which was one year ago.

In OFBIZ-10697 I wrote:

  <  By default OOTB debug.properties sets all debug levels to be 
used but verbose. So there is no point checking other levels than 
verbose to see if
  they are used, they are anyway. So OOTB only checking 
verbose is needed. That's what developers need.


  Now you invoked production where a different 
debug.properties setting would be used. Sincerely I'd never, 
never, remove the other levels than
  verbose from a production setting (as it's OOTB). I'd even 
be quite reluctant to remove any of those levels from a production 
site running for
  years! *You never know what can happen*, and those debug 
levels are your only lifebelt in case of issues, small and big ones.


  That's my point, and that's why I see checking if a level is 
used as premature optimisation but for verbose. We need them 
anyway and IMO setting
  false for any but verbose in debug.properties in production 
would be conceited if not "suicidal" . But maybe you have use 
cases I ignore?


  Anway, I'll start a discussion in dev ML about this point. 
Like I said above and in OFBIZ-10448 
<https://issues.apache.org/jira/browse/OFBIZ-10448>:


  I'd be all for removing the 312 useless cases but not 
the "if (Debug.verboseOn())">>


To what Michael answered

  <certainly won't run them on debug level info, verbose or debug.
  In my view, at least these 3 debug levels should be checked. 
At least, existing checks should not be removed.>>


I think Michael's point is perfectly valid. So I answered:

  <any issue in production needing an info or debug level.
  OK then we need to see things otherwise and rather enforce 
the checks to these 2 levels at least in all the source (Java and 
Groovy). That's what

  I'll ask in the convo to come in dev ML.>>

So what are your opinion about that? Should we enforce as suggest 
Michael or should we remove for the reasons I wrote.


I'd prefer to be consistent. So either we enforce the checks to 
the info, verbose and debug levels. Either we only keep the 
verbose checks.


Finally Mathieu has added a grain of salt:

  

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Jacques Le Roux]

Because

1. The if condition has a cost (3 times more than nothing according to 
Mathieu's reference[1])
2. and is not consistently used.
3. Using "Beautiful Logger" could be a better solution: 
https://github.com/forax/beautiful_logger
   drawbacks:
 *   needs Java 11 to build. But will we use Java 8 forever? Can run with 
Java 8.
 * "put more pressure to the JITs so it may lengthen the time to steady state of 
an application."

[1] https://www.youtube.com/watch?v=z5UkoLaW6ME (French)

Jacques

Le 11/12/2018 à 12:15, Taher Alkhateeb a écrit :

We already agreed and decided to keep the if condition. I'm not sure
why this subject is being reopened.
On Mon, Dec 10, 2018 at 9:49 PM Jacques Le Roux
 wrote:

The question is quite simple. It's about always using or not the /if 
(Debug.levelOn()) {/ expression for the info and debug level as suggests 
Michael.

Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend for the 
reasons explained.

I think we all agree the /if/ /(Debug.verboseOn()) { /should always be used and 
enforced when missing.

I put all the details/arguments to easily refer to them if needed.

Also Mathieu suggested to Michael to have a look at "Beautiful Logger" because 
he is concerned by the logging performance. We could also have a look
at it, to see if it could be integrated OOTB.

HTH

Jacques

Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have 
another discussion following https://markmail.org/message/mplvusuqn7oshl4v
which was one year ago.

In OFBIZ-10697 I wrote:

  :

  I'd be all for removing the 312 useless cases but not the "if 
(Debug.verboseOn())">>

To what Michael answered

  <>

I think Michael's point is perfectly valid. So I answered:

  <>

So what are your opinion about that? Should we enforce as suggest Michael or 
should we remove for the reasons I wrote.

I'd prefer to be consistent. So either we enforce the checks to the info, 
verbose and debug levels. Either we only keep the verbose checks.

Finally Mathieu has added a grain of salt:

  ,

  If you care about the impact of loggers on performance you should take a look 
at the Beautiful Logger 
  library by Remi Forax which implements a truly transparent logger. In a recent 
Devoxx talk  (in
  french) he showed that even doing if (Debug.logXXX()) has a 3x slowdown 
compared to a no-op.>>

So maybe we should have a closer look at  Beautiful Logger before taking any decision? 
Note that it uses JitPack, hence seems to need "Java 11 to build".

Thanks

Jacques

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Taher Alkhateeb]

We already agreed and decided to keep the if condition. I'm not sure
why this subject is being reopened.
On Mon, Dec 10, 2018 at 9:49 PM Jacques Le Roux
 wrote:
>
> The question is quite simple. It's about always using or not the /if 
> (Debug.levelOn()) {/ expression for the info and debug level as suggests 
> Michael.
>
> Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend for the 
> reasons explained.
>
> I think we all agree the /if/ /(Debug.verboseOn()) { /should always be used 
> and enforced when missing.
>
> I put all the details/arguments to easily refer to them if needed.
>
> Also Mathieu suggested to Michael to have a look at "Beautiful Logger" 
> because he is concerned by the logging performance. We could also have a look
> at it, to see if it could be integrated OOTB.
>
> HTH
>
> Jacques
>
> Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :
> > I didn't understand the exact decision required? To do what vs what?
> > On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
> >  wrote:
> >> Hi,
> >>
> >> After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have 
> >> another discussion following https://markmail.org/message/mplvusuqn7oshl4v
> >> which was one year ago.
> >>
> >> In OFBIZ-10697 I wrote:
> >>
> >>  < >>
> >>  By default OOTB debug.properties sets all debug levels to be used but 
> >> verbose. So there is no point checking other levels than verbose to see if
> >>  they are used, they are anyway. So OOTB only checking verbose is 
> >> needed. That's what developers need.
> >>
> >>  Now you invoked production where a different debug.properties setting 
> >> would be used. Sincerely I'd never, never, remove the other levels than
> >>  verbose from a production setting (as it's OOTB). I'd even be quite 
> >> reluctant to remove any of those levels from a production site running for
> >>  years! *You never know what can happen*, and those debug levels are 
> >> your only lifebelt in case of issues, small and big ones.
> >>
> >>  That's my point, and that's why I see checking if a level is used as 
> >> premature optimisation but for verbose. We need them anyway and IMO setting
> >>  false for any but verbose in debug.properties in production would be 
> >> conceited if not "suicidal" . But maybe you have use cases I ignore?
> >>
> >>  Anway, I'll start a discussion in dev ML about this point. Like I 
> >> said above and in OFBIZ-10448 
> >> <https://issues.apache.org/jira/browse/OFBIZ-10448>:
> >>
> >>  I'd be all for removing the 312 useless cases but not the "if 
> >> (Debug.verboseOn())">>
> >>
> >> To what Michael answered
> >>
> >>  < >> run them on debug level info, verbose or debug.
> >>  In my view, at least these 3 debug levels should be checked. At 
> >> least, existing checks should not be removed.>>
> >>
> >> I think Michael's point is perfectly valid. So I answered:
> >>
> >>  < >> in production needing an info or debug level.
> >>  OK then we need to see things otherwise and rather enforce the checks 
> >> to these 2 levels at least in all the source (Java and Groovy). That's what
> >>  I'll ask in the convo to come in dev ML.>>
> >>
> >> So what are your opinion about that? Should we enforce as suggest Michael 
> >> or should we remove for the reasons I wrote.
> >>
> >> I'd prefer to be consistent. So either we enforce the checks to the info, 
> >> verbose and debug levels. Either we only keep the verbose checks.
> >>
> >> Finally Mathieu has added a grain of salt:
> >>
> >>  < >> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mbrohl>,
> >>
> >>  If you care about the impact of loggers on performance you should 
> >> take a look at the Beautiful Logger 
> >> <https://github.com/forax/beautiful_logger>
> >>  library by Remi Forax which implements a truly transparent logger. In 
> >> a recent Devoxx talk <https://www.youtube.com/watch?v=z5UkoLaW6ME> (in
> >>  french) he showed that even doing if (Debug.logXXX()) has a 3x 
> >> slowdown compared to a no-op.>>
> >>
> >> So maybe we should have a closer look at  Beautiful Logger before taking 
> >> any decision? Note that it uses JitPack, hence seems to need "Java 11 to 
> >> build".
> >>
> >> Thanks
> >>
> >> Jacques
> >>

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Jacques Le Roux]

The question is quite simple. It's about always using or not the /if 
(Debug.levelOn()) {/ expression for the info and debug level as suggests 
Michael.

Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend for the 
reasons explained.

I think we all agree the /if/ /(Debug.verboseOn()) { /should always be used and 
enforced when missing.

I put all the details/arguments to easily refer to them if needed.

Also Mathieu suggested to Michael to have a look at "Beautiful Logger" because he is concerned by the logging performance. We could also have a look 
at it, to see if it could be integrated OOTB.


HTH

Jacques

Le 10/12/2018 à 18:02, Taher Alkhateeb a écrit :

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have 
another discussion following https://markmail.org/message/mplvusuqn7oshl4v
which was one year ago.

In OFBIZ-10697 I wrote:

 :

 I'd be all for removing the 312 useless cases but not the "if 
(Debug.verboseOn())">>

To what Michael answered

 <>

I think Michael's point is perfectly valid. So I answered:

 <>

So what are your opinion about that? Should we enforce as suggest Michael or 
should we remove for the reasons I wrote.

I'd prefer to be consistent. So either we enforce the checks to the info, 
verbose and debug levels. Either we only keep the verbose checks.

Finally Mathieu has added a grain of salt:

 ,

 If you care about the impact of loggers on performance you should take a look at 
the Beautiful Logger 
 library by Remi Forax which implements a truly transparent logger. In a recent 
Devoxx talk  (in
 french) he showed that even doing if (Debug.logXXX()) has a 3x slowdown compared 
to a no-op.>>

So maybe we should have a closer look at  Beautiful Logger before taking any decision? 
Note that it uses JitPack, hence seems to need "Java 11 to build".

Thanks

Jacques

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Taher Alkhateeb]

I didn't understand the exact decision required? To do what vs what?
On Mon, Dec 10, 2018 at 7:43 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have 
> another discussion following https://markmail.org/message/mplvusuqn7oshl4v
> which was one year ago.
>
> In OFBIZ-10697 I wrote:
>
> <
> By default OOTB debug.properties sets all debug levels to be used but 
> verbose. So there is no point checking other levels than verbose to see if
> they are used, they are anyway. So OOTB only checking verbose is needed. 
> That's what developers need.
>
> Now you invoked production where a different debug.properties setting 
> would be used. Sincerely I'd never, never, remove the other levels than
> verbose from a production setting (as it's OOTB). I'd even be quite 
> reluctant to remove any of those levels from a production site running for
> years! *You never know what can happen*, and those debug levels are your 
> only lifebelt in case of issues, small and big ones.
>
> That's my point, and that's why I see checking if a level is used as 
> premature optimisation but for verbose. We need them anyway and IMO setting
> false for any but verbose in debug.properties in production would be 
> conceited if not "suicidal" . But maybe you have use cases I ignore?
>
> Anway, I'll start a discussion in dev ML about this point. Like I said 
> above and in OFBIZ-10448 <https://issues.apache.org/jira/browse/OFBIZ-10448>:
>
> I'd be all for removing the 312 useless cases but not the "if 
> (Debug.verboseOn())">>
>
> To what Michael answered
>
> < them on debug level info, verbose or debug.
> In my view, at least these 3 debug levels should be checked. At least, 
> existing checks should not be removed.>>
>
> I think Michael's point is perfectly valid. So I answered:
>
> < production needing an info or debug level.
> OK then we need to see things otherwise and rather enforce the checks to 
> these 2 levels at least in all the source (Java and Groovy). That's what
> I'll ask in the convo to come in dev ML.>>
>
> So what are your opinion about that? Should we enforce as suggest Michael or 
> should we remove for the reasons I wrote.
>
> I'd prefer to be consistent. So either we enforce the checks to the info, 
> verbose and debug levels. Either we only keep the verbose checks.
>
> Finally Mathieu has added a grain of salt:
>
> < <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mbrohl>,
>
> If you care about the impact of loggers on performance you should take a 
> look at the Beautiful Logger <https://github.com/forax/beautiful_logger>
> library by Remi Forax which implements a truly transparent logger. In a 
> recent Devoxx talk <https://www.youtube.com/watch?v=z5UkoLaW6ME> (in
> french) he showed that even doing if (Debug.logXXX()) has a 3x slowdown 
> compared to a no-op.>>
>
> So maybe we should have a closer look at  Beautiful Logger before taking any 
> decision? Note that it uses JitPack, hence seems to need "Java 11 to build".
>
> Thanks
>
> Jacques
>

[DISCUSSION] Checking debug levels in Java and Groovy files

[Jacques Le Roux]

Hi,

After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have another discussion following https://markmail.org/message/mplvusuqn7oshl4v 
which was one year ago.


In OFBIZ-10697 I wrote:

   :

   I'd be all for removing the 312 useless cases but not the "if 
(Debug.verboseOn())">>

To what Michael answered

   <>

I think Michael's point is perfectly valid. So I answered:

   <>

So what are your opinion about that? Should we enforce as suggest Michael or 
should we remove for the reasons I wrote.

I'd prefer to be consistent. So either we enforce the checks to the info, 
verbose and debug levels. Either we only keep the verbose checks.

Finally Mathieu has added a grain of salt:

   ,

   If you care about the impact of loggers on performance you should take a look at 
the Beautiful Logger 
   library by Remi Forax which implements a truly transparent logger. In a recent 
Devoxx talk  (in
   french) he showed that even doing if (Debug.logXXX()) has a 3x slowdown compared 
to a no-op.>>

So maybe we should have a closer look at  Beautiful Logger before taking any decision? 
Note that it uses JitPack, hence seems to need "Java 11 to build".

Thanks

Jacques

Re: Using plain Groovy classes for services.

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux  writes:

> Le 21/11/2018 à 17:43, Jacques Le Roux a écrit :
>> Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit :
>>> For services I think the business logic and validation of data contained
>>> in services could often be extracted in separate unit testable methods
>>> which would allow cheap better case coverage to complement the
>>> integration test which is about checking that the service has the
>>> expected effect on the database.
>> Hi Mathieu,
>>
>> I see only one possible tiny drawback with this solution.
>>
>> I don't know you but most of the time, for small changes, I don't launch the 
>> integration tests, they are too long.
>> I wait for Buildbot feedback, which is most of the time not surprisingly 
>> good.
>>
>> Now every time we build OFBiz, the unit tests pass. Currently we have around 
>> thirty of them and they pass very quickly.
>> How many time it will take when we will have hundreds, if not thousands of 
>> them?
>>
>> Even if it's a small population, maybe we can already estimate an average 
>> time from the thirty we have?
>>
>> Thanks
>>
>> Jacques
>>
>>
> OK, I can answer to myself on this. This is not a problem at all.
> If someone thinks the test are too long in a particular circumstance
> s/he can use the same strategy that I often use for integration tests:
> skip them with "build -x test" and let Buildbot do the the work.

I think it is a good idea to run the unit tests before each commit which
is one of the reason why unit tests must be fast.

Currently we have 54 unit tests which takes 3+ seconds to compile and 7+
seconds to run on my machine.

To make this measurement I have deleted the ‘build’ directory.  Then I
have run the ‘classes’ task to compile every non test related classes.
I have measured the test compilation time with the ‘testClasses’ target
and test run time with the ‘test’ target.

Without considering the constant JVM warmup time and assuming linear
scalibity we could run about 400 unit tests in a minute.  However we
should expect better scalibity with modern multicore processors, since
unit tests are highly parallelizable because they don't rely on IO.  As
a consequence I bet we could have a few thousands of unit tests run in
less than a minute.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using plain Groovy classes for services.

[Jacques Le Roux]

Le 21/11/2018 à 17:43, Jacques Le Roux a écrit :

Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit :

For services I think the business logic and validation of data contained
in services could often be extracted in separate unit testable methods
which would allow cheap better case coverage to complement the
integration test which is about checking that the service has the
expected effect on the database.

Hi Mathieu,

I see only one possible tiny drawback with this solution.

I don't know you but most of the time, for small changes, I don't launch the 
integration tests, they are too long.
I wait for Buildbot feedback, which is most of the time not surprisingly good.

Now every time we build OFBiz, the unit tests pass. Currently we have around 
thirty of them and they pass very quickly.
How many time it will take when we will have hundreds, if not thousands of them?

Even if it's a small population, maybe we can already estimate an average time 
from the thirty we have?

Thanks

Jacques



OK, I can answer to myself on this. This is not a problem at all.
If someone thinks the test are too long in a particular circumstance s/he can use the same strategy that I often use for integration tests: skip them 
with "build -x test" and let Buildbot do the the work.


Jacques

Re: Using plain Groovy classes for services.

[Jacques Le Roux]

Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit :

For services I think the business logic and validation of data contained
in services could often be extracted in separate unit testable methods
which would allow cheap better case coverage to complement the
integration test which is about checking that the service has the
expected effect on the database.

Hi Mathieu,

I see only one possible tiny drawback with this solution.

I don't know you but most of the time, for small changes, I don't launch the 
integration tests, they are too long.
I wait for Buildbot feedback, which is most of the time not surprisingly good.

Now every time we build OFBiz, the unit tests pass. Currently we have around 
thirty of them and they pass very quickly.
How many time it will take when we will have hundreds, if not thousands of them?

Even if it's a small population, maybe we can already estimate an average time 
from the thirty we have?

Thanks

Jacques

Re: Using plain Groovy classes for services.

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb  writes:

> So I think we cannot look at things purely from a theoretical point of
> view. There has to be a balance between clean code and continued
> usability.
>
> Pros of your approach:
> - cleaner semantics
> - less pollution of the global namespace
> - the other benefits you mentioned
>
> Cons of your approach:
> - less orientation towards business focused individuals

The link between "business orientation" and the use of Groovy DSL is
only theoric.

> - more work on part of the developer. The DSL was always historically
> a comfort point for OFBiz not just the groovy DSL but XML and
> everything else.
> - Major amount of work to refactor all the services.

The amount of work is minimal in comparison to the effort of migrating
from Minilang to Groovy, since this is basically a matter of changing
the signature of the Groovy service and extracting the delegator and
dispatcher for the dispatch context parameter.

> I'm also not sure the problems you're facing are really that critical.

To make it clear this is not *my* problem.  As a professional programmer
I can live with this extra incidental complexity which only slows me
down.  The problem is in fact the one of the business people which have
to pay for this extra time.  :-)

> For example, you mentioned a con in unit-testing support functions?
> Really? It's a support function for a service, you _must_ have an
> integration test for that thing anyway. You cannot apply TDD on
> services, the nature of it is just not workable. And If you add unit
> tests your support functions you have now mixed production with test
> code without an obvious advantage (TDD is about millisecond tests).

The con I mentioned is theoric since, my experience in regard of unit
testing Groovy DSL code is based on testing the ‘GetLocaleList’ action
for the ‘LookupLocale’ screen.

For services I think the business logic and validation of data contained
in services could often be extracted in separate unit testable methods
which would allow cheap better case coverage to complement the
integration test which is about checking that the service has the
expected effect on the database.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using plain Groovy classes for services.

[Taher Alkhateeb]

So I think we cannot look at things purely from a theoretical point of
view. There has to be a balance between clean code and continued
usability.

Pros of your approach:
- cleaner semantics
- less pollution of the global namespace
- the other benefits you mentioned

Cons of your approach:
- less orientation towards business focused individuals
- more work on part of the developer. The DSL was always historically
a comfort point for OFBiz not just the groovy DSL but XML and
everything else.
- Major amount of work to refactor all the services.

I'm also not sure the problems you're facing are really that critical.
For example, you mentioned a con in unit-testing support functions?
Really? It's a support function for a service, you _must_ have an
integration test for that thing anyway. You cannot apply TDD on
services, the nature of it is just not workable. And If you add unit
tests your support functions you have now mixed production with test
code without an obvious advantage (TDD is about millisecond tests).

So weighing the pros and cons, and listening also to Jacopo's
feedback, I'm not sure this would be a highly valuable move.
On Wed, Nov 14, 2018 at 7:35 PM Mathieu Lirzin
 wrote:
>
> Hello Jacopo,
>
> Jacopo Cappellato  writes:
>
> > thank you for starting this interesting conversation.
> > I think it is fine to implement services in plain Java or in plain Groovy
> > methods and you have highlighted some of the advantages over their
> > implementation using the Groovy DSL.
> > However in my opinion the Groovy DSL (even in its current "basic" version,
> > implemented thru a few lines of code, that could be enhanced and extended)
> > has some advantages too and may be preferred by a different audience of
> > "users" that are more focused on business rules than on programming; data
> > preparation scripts are also a good fit for the DSL.
>
> Sure, allowing “business oriented” people to adapt OFBiz to their needs
> by letting them to automate a process in terms of business rules is
> *very* valuable.
>
> I never had the chance to exchange with people focused on business rules
> working with OFBiz which are able to write services/ECA/handlers.
> However I am rather skeptic regarding your claim that the Groovy service
> DSL allows a wider audience to adapt/compose OFBiz services to their
> needs.  I guess it serves more as a “fun” thing for programmers to play
> with, than something with an effective business value.
>
> In my opinion improving simplicity (locality, uniformity, value
> orientation, ...)  would be far more effective at empowering both
> business and code oriented programmers. [1]
>
> Thanks for sharing your view.
>
> [1] https://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using plain Groovy classes for services.

[Mathieu Lirzin]

Hello Jacopo,

Jacopo Cappellato  writes:

> thank you for starting this interesting conversation.
> I think it is fine to implement services in plain Java or in plain Groovy
> methods and you have highlighted some of the advantages over their
> implementation using the Groovy DSL.
> However in my opinion the Groovy DSL (even in its current "basic" version,
> implemented thru a few lines of code, that could be enhanced and extended)
> has some advantages too and may be preferred by a different audience of
> "users" that are more focused on business rules than on programming; data
> preparation scripts are also a good fit for the DSL.

Sure, allowing “business oriented” people to adapt OFBiz to their needs
by letting them to automate a process in terms of business rules is
*very* valuable.

I never had the chance to exchange with people focused on business rules
working with OFBiz which are able to write services/ECA/handlers.
However I am rather skeptic regarding your claim that the Groovy service
DSL allows a wider audience to adapt/compose OFBiz services to their
needs.  I guess it serves more as a “fun” thing for programmers to play
with, than something with an effective business value.

In my opinion improving simplicity (locality, uniformity, value
orientation, ...)  would be far more effective at empowering both
business and code oriented programmers. [1]

Thanks for sharing your view.

[1] https://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using plain Groovy classes for services.

[Jacopo Cappellato]

Hi Mathieu,

thank you for starting this interesting conversation.
I think it is fine to implement services in plain Java or in plain Groovy
methods and you have highlighted some of the advantages over their
implementation using the Groovy DSL.
However in my opinion the Groovy DSL (even in its current "basic" version,
implemented thru a few lines of code, that could be enhanced and extended)
has some advantages too and may be preferred by a different audience of
"users" that are more focused on business rules than on programming; data
preparation scripts are also a good fit for the DSL.

Just my two cents,

Jacopo

On Sun, Nov 11, 2018 at 8:02 PM Mathieu Lirzin 
wrote:

> Hello,
>
> While I think using Groovy for implementing services is a better choice
> than Java, I am not convinced by the rationale of using Groovy DSL
> features. Here are the various drawbacks I see:
>
>   - The service DSL breaks the function/method local scoping goodness by
> introducing various global variables (parameters, delegator, ...)
>
>   - There is no clear disctinction between services and helper methods
> (private/public)
>
>   - When Unit testing a helper method defined in a DSL script, a
> cumbersome mechanism for accessing the groovy method is required
>
>   - DSL implicit class context abstraction is leaky, for example it is
> hard to understand what is the proper way to define a variable
> outside of a method and how to refer to it from this method.
>
> def foo = "foo"
> def barService() {
> print foo // => ERROR: No such property: foo for class: ...
> }
>
> IMO DSL features introduce accidental complexity with very little
> benefits.  Since plain Groovy classes doesn't suffer from the downsides
> I described above and preserve the Groovy goodness (map literals,
> optional typing, ...), I recommend transitioning from DSL scripts to
> classes.
>
> What do people think?
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: Using plain Groovy classes for services.

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb  writes:

> Can you explain hat you want to do exactly? How do these services
> access the delegator and whatnot?

Basically what I have in mind, is to organize services in classes like
what is done in Java with the same method signature:

  (Map ⨯ Map) → Map

where the maps parameters correspond respectively to the “dispatch
context” and the “service input”.  The main difference with Java
services is the possibility to write map and list literals, and avoid
explicit typing with ‘def’.  Additionally it would be easy to provide a
method for the dispatcher which could reads like the current ‘run’
method of the DSL and provide the same semantics (throwing an exception
upon failure).  Something like:

  dispatcher.run service: "fooService" with: [...]

Thanks for your questions.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using plain Groovy classes for services.

[Taher Alkhateeb]

Hi Mathieu,

Can you explain hat you want to do exactly? How do these services
access the delegator and whatnot?
On Sun, Nov 11, 2018 at 5:32 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> While I think using Groovy for implementing services is a better choice
> than Java, I am not convinced by the rationale of using Groovy DSL
> features. Here are the various drawbacks I see:
>
>   - The service DSL breaks the function/method local scoping goodness by
> introducing various global variables (parameters, delegator, ...)
>
>   - There is no clear disctinction between services and helper methods
> (private/public)
>
>   - When Unit testing a helper method defined in a DSL script, a
> cumbersome mechanism for accessing the groovy method is required
>
>   - DSL implicit class context abstraction is leaky, for example it is
> hard to understand what is the proper way to define a variable
> outside of a method and how to refer to it from this method.
>
> def foo = "foo"
> def barService() {
> print foo // => ERROR: No such property: foo for class: ...
> }
>
> IMO DSL features introduce accidental complexity with very little
> benefits.  Since plain Groovy classes doesn't suffer from the downsides
> I described above and preserve the Groovy goodness (map literals,
> optional typing, ...), I recommend transitioning from DSL scripts to
> classes.
>
> What do people think?
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

答复: Using plain Groovy classes for services.

[Zhang Wei]

+1,

We can also use groovy for other java classes

发件人: Mathieu Lirzin 
发送时间: 2018年11月11日 23:32
收件人: OFBIZ Development Mailing List
主题: Using plain Groovy classes for services.

Hello,

While I think using Groovy for implementing services is a better choice
than Java, I am not convinced by the rationale of using Groovy DSL
features. Here are the various drawbacks I see:

  - The service DSL breaks the function/method local scoping goodness by
introducing various global variables (parameters, delegator, ...)

  - There is no clear disctinction between services and helper methods
(private/public)

  - When Unit testing a helper method defined in a DSL script, a
cumbersome mechanism for accessing the groovy method is required

  - DSL implicit class context abstraction is leaky, for example it is
hard to understand what is the proper way to define a variable
outside of a method and how to refer to it from this method.

def foo = "foo"
def barService() {
print foo // => ERROR: No such property: foo for class: ...
}

IMO DSL features introduce accidental complexity with very little
benefits.  Since plain Groovy classes doesn't suffer from the downsides
I described above and preserve the Groovy goodness (map literals,
optional typing, ...), I recommend transitioning from DSL scripts to
classes.

What do people think?

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Using plain Groovy classes for services.

[Mathieu Lirzin]

Hello,

While I think using Groovy for implementing services is a better choice
than Java, I am not convinced by the rationale of using Groovy DSL
features. Here are the various drawbacks I see:

  - The service DSL breaks the function/method local scoping goodness by
introducing various global variables (parameters, delegator, ...)

  - There is no clear disctinction between services and helper methods
(private/public)

  - When Unit testing a helper method defined in a DSL script, a
cumbersome mechanism for accessing the groovy method is required

  - DSL implicit class context abstraction is leaky, for example it is
hard to understand what is the proper way to define a variable
outside of a method and how to refer to it from this method.

def foo = "foo"
def barService() {
print foo // => ERROR: No such property: foo for class: ...
}

IMO DSL features introduce accidental complexity with very little
benefits.  Since plain Groovy classes doesn't suffer from the downsides
I described above and preserve the Groovy goodness (map literals,
optional typing, ...), I recommend transitioning from DSL scripts to
classes.

What do people think?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Groovy DSL runService Exception Management ?

[Gil Portenseigne]

Thanks Jacopo and Taher for your answers.

I understand now the goal of this and will try to use it to
allow less verbosity in service error handling management in Groovy DSL.

Indeed, in a way, each service using groovy should throw
ExecutionServiceException that should be managed within the
service engine itself.

In that way, there won't be needed systematic test against service return
in groovy and that is a good thing.


Gil

Le dimanche 21 oct. 2018 à 08:02:35 (+0200), Jacopo Cappellato a écrit :
> On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
> 
> > Hello !
> >
> > While we are working on Groovy migration at Nereide, we figured out that
> > using ‘run service’ DSL method instead of returning the errorMap, a
> > ‘ExecutionServiceException’ is thrown
> 
> [...]
> > I wonder if exception management is more costly than simple return.
> > May the GroovyEngine should handle the exception ? I do not grasp yet
> > the benenit of this implementation.
> >
> 
>  Hi Gil,
> 
> if I recall correctly, the original goal was to implement a behavior
> similar to the default one of Minilang: if an error is thrown during the
> execution of the "call-service" directive in Minilang then the script
> execution is halted (see the definition of the property "break-on-error").
> 
> I hope it makes sense,
> 
> Jacopo

Re: Groovy DSL runService Exception Management ?

[Jacopo Cappellato]

On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello !
>
> While we are working on Groovy migration at Nereide, we figured out that
> using ‘run service’ DSL method instead of returning the errorMap, a
> ‘ExecutionServiceException’ is thrown

[...]
> I wonder if exception management is more costly than simple return.
> May the GroovyEngine should handle the exception ? I do not grasp yet
> the benenit of this implementation.
>

 Hi Gil,

if I recall correctly, the original goal was to implement a behavior
similar to the default one of Minilang: if an error is thrown during the
execution of the "call-service" directive in Minilang then the script
execution is halted (see the definition of the property "break-on-error").

I hope it makes sense,

Jacopo

Re: Groovy DSL runService Exception Management ?

[Taher Alkhateeb]

Well, I'm not sure what's the best approach, but your suggestion would
perhaps add more verbosity and so needs to have a reason.

Exceptions are not always necessarily a "bad" thing, they're just a
language feature to indicate a different path of execution, so
bubbling an exception to stop a service sounds reasonable and might be
even a better approach because if you have very complex logic then you
can just let the exception bubble up until it stop the service hence
reverting all DB changes.

I could be wrong or missing something of course, so opinions might
enrich the discussion here.
On Thu, Oct 18, 2018 at 11:45 AM Gil Portenseigne
 wrote:
>
> Hello !
>
> While we are working on Groovy migration at Nereide, we figured out that
> using ‘run service’ DSL method instead of returning the errorMap, a
> ‘ExecutionServiceException’ is thrown :
>
> if (ServiceUtil.isError(result)) {
> throw new
> ExecutionServiceException(ServiceUtil.getErrorMessage(result))
> }
>
> Can anyone explain the intention behind that implementation ?
>
> I suppose that we need to catch any service call like :
>
> try {
> serviceResult = run service: 'createQuoteAdjustment', with:
> [*: quoteAdjustement, quoteId: quoteIdTo]
> } catch (ExecutionServiceException e) {
> return ServiceUtil.returnError(e.getMessage())
> }
>
> instead of :
>
> serviceResult = run service: 'createQuoteAdjustment', with:
> [*: quoteAdjustement, quoteId: quoteIdTo]
>
> if (ServiceUtil.isError(serviceResult)) {
> return serviceResult
> }
>
> I wonder if exception management is more costly than simple return.
> May the GroovyEngine should handle the exception ? I do not grasp yet
> the benenit of this implementation.
>
> What is the good way to handle service errors within services in Groovy?
>
> Thanks
>
> Gil

Groovy DSL runService Exception Management ?

[Gil Portenseigne]

Hello !

While we are working on Groovy migration at Nereide, we figured out that
using ‘run service’ DSL method instead of returning the errorMap, a
‘ExecutionServiceException’ is thrown :

if (ServiceUtil.isError(result)) {
throw new
ExecutionServiceException(ServiceUtil.getErrorMessage(result))
}

Can anyone explain the intention behind that implementation ?

I suppose that we need to catch any service call like :

try {
serviceResult = run service: 'createQuoteAdjustment', with:
[*: quoteAdjustement, quoteId: quoteIdTo]
} catch (ExecutionServiceException e) {
return ServiceUtil.returnError(e.getMessage())
}

instead of : 

serviceResult = run service: 'createQuoteAdjustment', with:
[*: quoteAdjustement, quoteId: quoteIdTo]

if (ServiceUtil.isError(serviceResult)) {
return serviceResult
}

I wonder if exception management is more costly than simple return.
May the GroovyEngine should handle the exception ? I do not grasp yet
the benenit of this implementation.

What is the good way to handle service errors within services in Groovy?

Thanks

Gil

Re: Error in groovy files only inside docker

[Jacques Le Roux]

And please Alberto, don't use the dev ML for such questions, see why at 
http://ofbiz.apache.org/mailing-lists.html

BTW your email has been moderated, please subscribe to the MLs you want to use

Thanks and welcome

Jacques


Le 05/09/2018 à 10:10, Taher Alkhateeb a écrit :

Probably nothing to do with docker but rather the environment setup. Check
Java version and your build script and make sure everything is setup
correctly.

On Wed, Sep 5, 2018, 11:05 AM albertooli...@gmail.com <
albertooli...@gmail.com> wrote:


Hello everyone!

I am customizing a plugin with ofbiz (new screens and entities, not groovy
at all), and in my local computer (Windows 10, jdk8_171) works prety fine,
but when I build a docker image and deploy it (Linux), some screens have
Exceptions, and also lookups show groovy errors.


This screen is webTools -> Service Engine

2018-09-04 12:57:07,268 |http-nio-8443-exec-1 |ControlServlet
   |E| Error in request handler:
org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
screen [component://webtools/widget/ServiceScreens.xml#ServiceList]:
java.lang.IllegalArgumentException: Error running script at location
[component://webtools/groovyScripts/service/AvailableServices.groovy]:
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
[component://webtools/groovyScripts/service/AvailableServices.groovy]:
(startup failed:
component://webtools/groovyScripts/service/AvailableServices.groovy: 334:
A transform used a generics containing ClassNode
org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
AvailableServices directly. You are not supposed to do this. Please create
a new ClassNode referring to the old ClassNode and use the new ClassNode
instead of the old one. Otherwise the compiler will create wrong
descriptors and a potential NullPointerException in TypeResolver in the
OpenJDK. If this is not your own doing, please report this bug to the
writer of the transform.
@ line 334, column 1.
dispArrList = new TreeSet()
^

1 error


Then, in Log Screen:

2018-09-04 12:57:36,416 |http-nio-8443-exec-7 |ModelScreen
|E| Error rendering screen
[component://webtools/widget/LogScreens.xml#LogView]:
java.lang.IllegalArgumentException: Error running script at location
[component://webtools/groovyScripts/log/FetchLogs.groovy]:
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
[component://webtools/groovyScripts/log/FetchLogs.groovy]:  (startup failed:
component://webtools/groovyScripts/log/FetchLogs.groovy: 23: A transform
used a generics containing ClassNode
org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
FetchLogs directly. You are not supposed to do this. Please create a new
ClassNode referring to the old ClassNode and use the new ClassNode instead
of the old one. Otherwise the compiler will create wrong descriptors and a
potential NullPointerException in TypeResolver in the OpenJDK. If this is
not your own doing, please report this bug to the writer of the transform.
@ line 23, column 1.
String ofbizLogDir = UtilProperties.getPropertyValue("debug",
"log4j.appender.css.dir", "runtime/logs/")
^

1 error


And in my custom Lookpus, the screen does not fails completly, but shows
this error in the dinamic groovy part of the field:


org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
screen [component://common/widget/CommonScreens.xml#LookupDecorator]:
java.lang.IllegalArgumentException: Error running script at location
[component://common/groovyScripts/FindAutocompleteOptions.groovy]:
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script
at [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
(startup failed:
component://common/groovyScripts/FindAutocompleteOptions.groovy: 32:
A transform used a generics containing ClassNode
org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
FindAutocompleteOptions directly.
You are not supposed to do this. Please create a new ClassNode referring
to the old ClassNode and use the new ClassNode instead of the old one.
Otherwise the compiler will create wrong descriptors and a potential
NullPointerException in TypeResolver in the OpenJDK.
If this is not your own doing, please report this bug to the writer of the
transform. @ line 32, column 1. def mainAndConds = [] ^ 1 error )
(Error running script at location
[component://common/groovyScripts/FindAutocompleteOptions.groovy]:


Any suggestions why only fails in docker/linux?

Thanks in advance!

Re: Error in groovy files only inside docker

[Taher Alkhateeb]

Probably nothing to do with docker but rather the environment setup. Check
Java version and your build script and make sure everything is setup
correctly.

On Wed, Sep 5, 2018, 11:05 AM albertooli...@gmail.com <
albertooli...@gmail.com> wrote:

> Hello everyone!
>
> I am customizing a plugin with ofbiz (new screens and entities, not groovy
> at all), and in my local computer (Windows 10, jdk8_171) works prety fine,
> but when I build a docker image and deploy it (Linux), some screens have
> Exceptions, and also lookups show groovy errors.
>
>
> This screen is webTools -> Service Engine
>
> 2018-09-04 12:57:07,268 |http-nio-8443-exec-1 |ControlServlet
>   |E| Error in request handler:
> org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
> screen [component://webtools/widget/ServiceScreens.xml#ServiceList]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://webtools/groovyScripts/service/AvailableServices.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
> [component://webtools/groovyScripts/service/AvailableServices.groovy]:
> (startup failed:
> component://webtools/groovyScripts/service/AvailableServices.groovy: 334:
> A transform used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> AvailableServices directly. You are not supposed to do this. Please create
> a new ClassNode referring to the old ClassNode and use the new ClassNode
> instead of the old one. Otherwise the compiler will create wrong
> descriptors and a potential NullPointerException in TypeResolver in the
> OpenJDK. If this is not your own doing, please report this bug to the
> writer of the transform.
> @ line 334, column 1.
>dispArrList = new TreeSet()
>^
>
> 1 error
>
>
> Then, in Log Screen:
>
> 2018-09-04 12:57:36,416 |http-nio-8443-exec-7 |ModelScreen
>|E| Error rendering screen
> [component://webtools/widget/LogScreens.xml#LogView]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://webtools/groovyScripts/log/FetchLogs.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at
> [component://webtools/groovyScripts/log/FetchLogs.groovy]:  (startup failed:
> component://webtools/groovyScripts/log/FetchLogs.groovy: 23: A transform
> used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> FetchLogs directly. You are not supposed to do this. Please create a new
> ClassNode referring to the old ClassNode and use the new ClassNode instead
> of the old one. Otherwise the compiler will create wrong descriptors and a
> potential NullPointerException in TypeResolver in the OpenJDK. If this is
> not your own doing, please report this bug to the writer of the transform.
> @ line 23, column 1.
>String ofbizLogDir = UtilProperties.getPropertyValue("debug",
> "log4j.appender.css.dir", "runtime/logs/")
>^
>
> 1 error
>
>
> And in my custom Lookpus, the screen does not fails completly, but shows
> this error in the dinamic groovy part of the field:
>
>
> org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering
> screen [component://common/widget/CommonScreens.xml#LookupDecorator]:
> java.lang.IllegalArgumentException: Error running script at location
> [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
> org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script
> at [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
> (startup failed:
> component://common/groovyScripts/FindAutocompleteOptions.groovy: 32:
> A transform used a generics containing ClassNode
> org.apache.ofbiz.service.engine.GroovyBaseScript for the super class
> FindAutocompleteOptions directly.
> You are not supposed to do this. Please create a new ClassNode referring
> to the old ClassNode and use the new ClassNode instead of the old one.
> Otherwise the compiler will create wrong descriptors and a potential
> NullPointerException in TypeResolver in the OpenJDK.
> If this is not your own doing, please report this bug to the writer of the
> transform. @ line 32, column 1. def mainAndConds = [] ^ 1 error )
> (Error running script at location
> [component://common/groovyScripts/FindAutocompleteOptions.groovy]:
>
>
> Any suggestions why only fails in docker/linux?
>
> Thanks in advance!
>

Error in groovy files only inside docker

[albertoolivan]

Hello everyone!

I am customizing a plugin with ofbiz (new screens and entities, not groovy at 
all), and in my local computer (Windows 10, jdk8_171) works prety fine, but 
when I build a docker image and deploy it (Linux), some screens have 
Exceptions, and also lookups show groovy errors.


This screen is webTools -> Service Engine

2018-09-04 12:57:07,268 |http-nio-8443-exec-1 |ControlServlet
|E| Error in request handler:
org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://webtools/widget/ServiceScreens.xml#ServiceList]: 
java.lang.IllegalArgumentException: Error running script at location 
[component://webtools/groovyScripts/service/AvailableServices.groovy]: 
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at 
[component://webtools/groovyScripts/service/AvailableServices.groovy]:  
(startup failed:
component://webtools/groovyScripts/service/AvailableServices.groovy: 334: A 
transform used a generics containing ClassNode 
org.apache.ofbiz.service.engine.GroovyBaseScript for the super class 
AvailableServices directly. You are not supposed to do this. Please create a 
new ClassNode referring to the old ClassNode and use the new ClassNode instead 
of the old one. Otherwise the compiler will create wrong descriptors and a 
potential NullPointerException in TypeResolver in the OpenJDK. If this is not 
your own doing, please report this bug to the writer of the transform.
@ line 334, column 1.
   dispArrList = new TreeSet()
   ^

1 error


Then, in Log Screen:

2018-09-04 12:57:36,416 |http-nio-8443-exec-7 |ModelScreen   
|E| Error rendering screen 
[component://webtools/widget/LogScreens.xml#LogView]: 
java.lang.IllegalArgumentException: Error running script at location 
[component://webtools/groovyScripts/log/FetchLogs.groovy]: 
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at 
[component://webtools/groovyScripts/log/FetchLogs.groovy]:  (startup failed:
component://webtools/groovyScripts/log/FetchLogs.groovy: 23: A transform used a 
generics containing ClassNode org.apache.ofbiz.service.engine.GroovyBaseScript 
for the super class FetchLogs directly. You are not supposed to do this. Please 
create a new ClassNode referring to the old ClassNode and use the new ClassNode 
instead of the old one. Otherwise the compiler will create wrong descriptors 
and a potential NullPointerException in TypeResolver in the OpenJDK. If this is 
not your own doing, please report this bug to the writer of the transform.
@ line 23, column 1.
   String ofbizLogDir = UtilProperties.getPropertyValue("debug", 
"log4j.appender.css.dir", "runtime/logs/")
   ^

1 error


And in my custom Lookpus, the screen does not fails completly, but shows this 
error in the dinamic groovy part of the field:


org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://common/widget/CommonScreens.xml#LookupDecorator]: 
java.lang.IllegalArgumentException: Error running script at location 
[component://common/groovyScripts/FindAutocompleteOptions.groovy]: 
org.apache.ofbiz.base.util.GeneralException: Error loading Groovy script at 
[component://common/groovyScripts/FindAutocompleteOptions.groovy]: 
(startup failed: 
component://common/groovyScripts/FindAutocompleteOptions.groovy: 32: 
A transform used a generics containing ClassNode 
org.apache.ofbiz.service.engine.GroovyBaseScript for the super class 
FindAutocompleteOptions directly. 
You are not supposed to do this. Please create a new ClassNode referring to the 
old ClassNode and use the new ClassNode instead of the old one. 
Otherwise the compiler will create wrong descriptors and a potential 
NullPointerException in TypeResolver in the OpenJDK. 
If this is not your own doing, please report this bug to the writer of the 
transform. @ line 32, column 1. def mainAndConds = [] ^ 1 error ) 
(Error running script at location 
[component://common/groovyScripts/FindAutocompleteOptions.groovy]: 


Any suggestions why only fails in docker/linux?

Thanks in advance!

Re: svn commit: r1827470 - /ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests .groovy

[Jacques Le Roux]

I guess you mean replace by .adoc files?

Jacques



Le 22/03/2018 à 10:32, Taher Alkhateeb a écrit :

Just a note to all the documentation team, I think we should probably
delete most README files anyway. The manual should be comprehensive
and incorporate whatever is documented in these README files

On Thu, Mar 22, 2018 at 11:54 AM,   wrote:

Author: pgil
Date: Thu Mar 22 08:54:00 2018
New Revision: 1827470

URL: http://svn.apache.org/viewvc?rev=1827470&view=rev
Log:
Fixed: Convert README.md to README.adoc.
(OFBIZ-10272)

Complete Jacques Fix, replacing all README.md occurence with README.adoc.

Modified:
 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy

Modified: 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy?rev=1827470&r1=1827469&r2=1827470&view=diff
==
--- 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
 Thu Mar 22 08:54:00 2018
@@ -26,15 +26,15 @@ import org.apache.ofbiz.testtools.Groovy
  class FileUtilTests extends GroovyScriptTestCase {

  /**
- * Test FileUtil zipFileStream and unzipFileToFolder methods, using 
README.md
+ * Test FileUtil zipFileStream and unzipFileToFolder methods, using 
README.adoc
   */
  void testZipReadme() {
  String zipFilePath = UtilProperties.getPropertyValue("general", 
"http.upload.tmprepository", "runtime/tmp")
-String zipName = 'README.md.zip'
+String zipName = 'README.adoc.zip'
  String fileName = 'README.adoc'
  File originalReadme = new File(fileName)

-//validate zipStream from README.md is not null
+//validate zipStream from README.adoc is not null
  def zipStream = 
FileUtil.zipFileStream(originalReadme.newInputStream(), fileName)
  assert zipStream

@@ -52,7 +52,7 @@ class FileUtilTests extends GroovyScript
  out.close()
  zipStream.close()

-//ensure no README.md exist in tmp folder
+//ensure no README.adoc exist in tmp folder
  File readme = new File(zipFilePath, fileName)
  if (readme.exists()) readme.delete()

Re: svn commit: r1827457 - /ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests .groovy

[Jacques Le Roux]

You'r right, thanks Gil

Jacques


Le 22/03/2018 à 08:48, gil portenseigne a écrit :

Indeed, thanks Jacques for the fix.

I'll just complete it renaming the zipName to README.adoc.zip :), not a big 
deal but for consistency it's better.

Gil


On 22/03/2018 06:30, jler...@apache.org wrote:

Author: jleroux
Date: Thu Mar 22 05:30:39 2018
New Revision: 1827457

URL: http://svn.apache.org/viewvc?rev=1827457&view=rev
Log:
Fixed: Convert README.md to README.adoc.
(OFBIZ-10272)

Not sure why it went unnoticed so long, but by removing README.md
(replacing README.adoc) r1827046 brokes testZipReadme

Not a big deal, we can just replace the file in the test (from README.md to
README.adoc). We could chose a more sure to remain file, but I guess that now we
are going with asciidoc and README.adoc should stay

Modified:
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy

Modified: 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy?rev=1827457&r1=1827456&r2=1827457&view=diff

==
--- 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests.groovy
 Thu Mar 22 05:30:39 2018
@@ -31,7 +31,7 @@ class FileUtilTests extends GroovyScript
  void testZipReadme() {
  String zipFilePath = UtilProperties.getPropertyValue("general", 
"http.upload.tmprepository", "runtime/tmp")
  String zipName = 'README.md.zip'
-    String fileName = 'README.md'
+    String fileName = 'README.adoc'
  File originalReadme = new File(fileName)
    //validate zipStream from README.md is not null