Re: Community Over Code Bratislava 2024

[Gil Portenseigne]

Hi all, 

Just to let you know we just met after this email ! 

A great pleasure, we hope to meet more people  :)

Regards

Gil

Le 3 juin 2024 10:20:36 GMT+02:00, Giulio Speri - MpStyle Srl 
 a écrit :
>Good morning devs,
>
>Me and my colleague Nicola are attending the Community Over Code Event in
>Bratislava.
>Is any of you also participating? It would be great to meet you in person!
>:)
>
>Have a nice day,
>Giulio

[jira] [Closed] (OFBIZ-11067) Migrate integration tests to unit tests when possible

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-11067.

Resolution: Fixed

Thanks Gaëtan for your catch and contribution !

> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Mathieu Lirzin
>    Assignee: Gil Portenseigne
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch, 
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch, 
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch, 
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch, 
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch, 
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch, 
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch, 
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch, 
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests-1.patch,
>  
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests-1.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests.patch,
>  
> Patch_with_FlexibleMapAccessorTests_included_that_was_forgotten_in_the_previous_patch.patch
>
>
> In OFBiz there are both unit tests and integration tests which are 
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}. 
> However some integration tests are in fact unit tests that doesn't depend on 
> the entity and service engines. Those unit tests should run on the their 
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3 
> which is what is done for the integration test suite.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-11067) Migrate integration tests to unit tests when possible

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837261#comment-17837261
 ] 

Gil Portenseigne commented on OFBIZ-11067:
--

Hi [~jleroux] , if you don't mind, i will take care of it at the same time.
There is a git move and this modification in the patch to make the  
FlexibleMapAccessorTests run.

> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Mathieu Lirzin
>    Assignee: Gil Portenseigne
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch, 
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch, 
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch, 
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch, 
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch, 
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch, 
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch, 
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch, 
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests-1.patch,
>  
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests-1.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests.patch,
>  
> Patch_with_FlexibleMapAccessorTests_included_that_was_forgotten_in_the_previous_patch.patch
>
>
> In OFBiz there are both unit tests and integration tests which are 
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}. 
> However some integration tests are in fact unit tests that doesn't depend on 
> the entity and service engines. Those unit tests should run on the their 
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3 
> which is what is done for the integration test suite.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (OFBIZ-11067) Migrate integration tests to unit tests when possible

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne reassigned OFBIZ-11067:


Assignee: Gil Portenseigne  (was: Jacques Le Roux)

> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Mathieu Lirzin
>    Assignee: Gil Portenseigne
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch, 
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch, 
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch, 
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch, 
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch, 
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch, 
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch, 
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch, 
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests-1.patch,
>  
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests-1.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests.patch
>
>
> In OFBiz there are both unit tests and integration tests which are 
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}. 
> However some integration tests are in fact unit tests that doesn't depend on 
> the entity and service engines. Those unit tests should run on the their 
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3 
> which is what is done for the integration test suite.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-11067) Migrate integration tests to unit tests when possible

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837094#comment-17837094
 ] 

Gil Portenseigne commented on OFBIZ-11067:
--

i do it this day :D

> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Mathieu Lirzin
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch, 
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch, 
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch, 
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch, 
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch, 
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch, 
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch, 
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch, 
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests-1.patch,
>  
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests-1.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests.patch
>
>
> In OFBiz there are both unit tests and integration tests which are 
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}. 
> However some integration tests are in fact unit tests that doesn't depend on 
> the entity and service engines. Those unit tests should run on the their 
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3 
> which is what is done for the integration test suite.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836265#comment-17836265
 ] 

Gil Portenseigne commented on OFBIZ-13009:
--

oops, i failed codenarc rules, that is now fixed. Closing

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-13009.

Resolution: Fixed

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-13009:
-
Fix Version/s: Upcoming Branch

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-13003) Fix Assetmain Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-13003.

Resolution: Fixed

> Fix Assetmain Groovy tests
> --
>
> Key: OFBIZ-13003
> URL: https://issues.apache.org/jira/browse/OFBIZ-13003
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: assetmaint
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.assetmaint.test.FixedAssetMaintTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836246#comment-17836246
 ] 

Gil Portenseigne commented on OFBIZ-13009:
--

yes, seems fix, a last check before i push :)

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>    Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-13009:
-
Affects Version/s: Upcoming Branch

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13003) Fix Assetmain Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836247#comment-17836247
 ] 

Gil Portenseigne commented on OFBIZ-13003:
--

[https://ci2.apache.org/#/builders/46/builds/805] OK, closing.

> Fix Assetmain Groovy tests
> --
>
> Key: OFBIZ-13003
> URL: https://issues.apache.org/jira/browse/OFBIZ-13003
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: assetmaint
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.assetmaint.test.FixedAssetMaintTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-13009:


 Summary: Fix Ecommerce Groovy tests
 Key: OFBIZ-13009
 URL: https://issues.apache.org/jira/browse/OFBIZ-13009
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


|E| Unable to load test suite class │aucune modification n'a été ajoutée à la 
validation (utilisez "git add" ou "git commit -a")
: org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-13009) Fix Ecommerce Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-13009:
-
Description: Unable to load test suite class : 
org.apache.ofbiz.ecommerce.OrderNotificationTests  (was: |E| Unable to load 
test suite class │aucune modification n'a été ajoutée à la validation (utilisez 
"git add" ou "git commit -a")
: org.apache.ofbiz.ecommerce.OrderNotificationTests)

> Fix Ecommerce Groovy tests
> --
>
> Key: OFBIZ-13009
> URL: https://issues.apache.org/jira/browse/OFBIZ-13009
> Project: OFBiz
>  Issue Type: Sub-task
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
>
> Unable to load test suite class : 
> org.apache.ofbiz.ecommerce.OrderNotificationTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13006) Reject wrong URLs

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836193#comment-17836193
 ] 

Gil Portenseigne commented on OFBIZ-13006:
--

Hello [~jleroux] , there might be an issue with the trunk commit, see 
[https://ci2.apache.org/#/builders/49/builds/866/steps/2/logs/stdio]

> Reject wrong URLs
> -
>
> Key: OFBIZ-13006
> URL: https://issues.apache.org/jira/browse/OFBIZ-13006
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework/webapp
>Affects Versions: 18.12.13
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 18.12.13
>
>
> Some URLs need to be rejected before they create problems



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13003) Fix Assetmain Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836189#comment-17836189
 ] 

Gil Portenseigne commented on OFBIZ-13003:
--

Strange, the test was a success on my local, but not for buildbot... Let me 
check

> Fix Assetmain Groovy tests
> --
>
> Key: OFBIZ-13003
> URL: https://issues.apache.org/jira/browse/OFBIZ-13003
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: assetmaint
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.assetmaint.test.FixedAssetMaintTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-13003) Fix Assetmain Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835799#comment-17835799
 ] 

Gil Portenseigne commented on OFBIZ-13003:
--

I am not sure about if others test already comply with F.I.R.S.T. principle, 
but i think we should make those test independent from each others. 
I'll will create a data for the failing test.

> Fix Assetmain Groovy tests
> --
>
> Key: OFBIZ-13003
> URL: https://issues.apache.org/jira/browse/OFBIZ-13003
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: assetmaint
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Unable to load test suite class : 
> org.apache.ofbiz.assetmaint.test.FixedAssetMaintTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-11067) Migrate integration tests to unit tests when possible

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835187#comment-17835187
 ] 

Gil Portenseigne commented on OFBIZ-11067:
--

Sure, i will when i got some time :)

> Migrate integration tests to unit tests when possible
> -
>
> Key: OFBIZ-11067
> URL: https://issues.apache.org/jira/browse/OFBIZ-11067
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Mathieu Lirzin
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 
> OFBIZ-11067_0001-Turn-UtilPropertiesTests-into-a-unit-test-c.patch, 
> OFBIZ-11067_0002-Turn-ComparableRangeTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0003-Turn-DateTimeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0004-Turn-GenericMapTest-into-a-unit-test-class.patch, 
> OFBIZ-11067_0005-Turn-IndentingWriterTests-into-a-unit-test-.patch, 
> OFBIZ-11067_0006-Turn-MiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0007-Turn-ObjectTypeTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0008-Turn-ReferenceCleanerTests-into-a-unit-test.patch, 
> OFBIZ-11067_0009-Turn-TimeDurationTests-into-a-unit-test-cla.patch, 
> OFBIZ-11067_0010-Turn-UtilCacheTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0011-Remove-empty-UtilHttpTests-class.patch, 
> OFBIZ-11067_0012-Turn-UtilIOTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0013-Turn-UtilMiscTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0014-Turn-AssertTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0015-Turn-BaseUnitTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0016-Turn-TestBooleanConverters-into-a-unit-test.patch, 
> OFBIZ-11067_0017-Turn-TestJSONConverters-into-a-unit-test-cl.patch, 
> OFBIZ-11067_0018-Turn-UtilObjectTests-into-a-unit-test-class.patch, 
> OFBIZ-11067_0019-Merge-UtilObjectUnitTest-into-UtilObjectTes.patch, 
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests-1.patch,
>  
> OFBIZ-11067_fixes_FlexibleStringExpanderTests_and_FlexibleMapAcessor_tests.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests-1.patch,
>  
> OFBIZ-11067_turns_FlexibleMapAccessorTests_and_FlexibleStringExpanderTests_into_unit_tests.patch
>
>
> In OFBiz there are both unit tests and integration tests which are 
> respectively run by {{./gradlew test}} and {{./gradlew testIntegration}}. 
> However some integration tests are in fact unit tests that doesn't depend on 
> the entity and service engines. Those unit tests should run on the their 
> appropriate task.
> To do that it is necessary to convert them to use Junit4 instead of Junit3 
> which is what is done for the integration test suite.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12998) Fix Partymgr Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834430#comment-17834430
 ] 

Gil Portenseigne commented on OFBIZ-12998:
--

Thanks Jacques for the review, i checked in my local, but must have missed it ! 
Was to eager to end the mission this afternoon :)

> Fix Partymgr Groovy tests
> -
>
> Key: OFBIZ-12998
> URL: https://issues.apache.org/jira/browse/OFBIZ-12998
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Upcoming Branch
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
>
> This Jira intend to fix party component groovy integration tests : 
> 2024-04-05 14:12:56,111 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.party.PartyTests
> 2024-04-05 14:12:56,125 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.ContactMechWorkerTests
> 2024-04-05 14:12:56,126 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyContactMechTests
> 2024-04-05 14:12:56,134 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyStatusChangeTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12985) Integration Groovy tests fail

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834380#comment-17834380
 ] 

Gil Portenseigne commented on OFBIZ-12985:
--

i'll stop for now it remains : 
 org.apache.ofbiz.base.util.UtilObjectTests >>> seems to not be integration 
test, but unit. So should remove in testdef
Havent check the other yet.
org.apache.ofbiz.marketing.MarketingTests
 org.apache.ofbiz.assetmaint.test.FixedAssetMaintTests
org.apache.ofbiz.ecommerce.OrderNotificationTests

> Integration Groovy tests fail
> -
>
> Key: OFBIZ-12985
> URL: https://issues.apache.org/jira/browse/OFBIZ-12985
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS, ALL PLUGINS
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: Upcoming Branch
>
>
> Groovy testIntegration, tests suites and tests cases no longer work
> For my own help here is a simple case to test
> bq. "ofbiz --test component=accounting --test suitename=invoicetests --test 
> testcase=invoice-per-shipment-tests"
> It seems testIntegrations work but when you look at the log you find a lot of 
> (46, barely same than number of files: 44, did not digg more) "Unable to load 
> test suite class" errors like this 1st one:
> {noformat} 
> |ModelTestSuite|E|Unable to load test suite class : 
> org.apache.ofbiz.party.PartyTests|
> {noformat} 
> You can find that in last ofbizTrunkFrameworkPlugins BB build: 
> [https://ci2.apache.org/#/builders/46/builds/777]
> The result seems successful. It's a misleading testIntegration result (not 
> sure what does that) and an already old one. TestIntegrations still work in 
> 18.12 and the issue is somehow related to OFBIZ-12813.
> It's a really confusing situation. Several issues prevent Groovy tests to 
> work.
> The reason is due to wrong Groovy tests package names and locations due to 
> OFBIZ-12813
> If we refer to our way of naming packages they are correctly referenced in 
> testdef (eg org.apache.ofbiz.accounting vs org.apache.accounting.accounting)
> So it's only a simple packages names and locations changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12999) Fix Product Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12999.

Resolution: Fixed

[https://ci2.apache.org/#/builders/49/builds/851] OK !

> Fix Product Groovy tests
> 
>
> Key: OFBIZ-12999
> URL: https://issues.apache.org/jira/browse/OFBIZ-12999
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: product
>Affects Versions: Upcoming Branch
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
>
> This Jira intend to fix product component groovy integration tests : 
> 2024-04-05 10:33:05,904 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.product.ProductPriceTests
> 2024-04-05 10:33:05,906 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.CategoryTests
> 2024-04-05 10:33:05,921 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.InventoryTests
> 2024-04-05 10:33:05,923 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.ShipmentTests
> 2024-04-05 10:33:05,939 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.CostTests
> 2024-04-05 10:33:05,960 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.ProductTagTest
> 2024-04-05 10:33:05,973 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.ProductTest
> 2024-04-05 10:33:05,975 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.product.ProductTests
> 2024-04-05 10:33:05,976 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.product.ProductFeatureTypeTests
> 2024-04-05 10:33:05,991 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.product.ProductPromoCondTests
> 2024-04-05 10:33:05,995 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.product.ProductPromoActionTests
> 2024-04-05 10:33:06,013 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.product.ProductConfigTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-13000) Fix Order Groovy tests

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-13000:


 Summary: Fix Order Groovy tests
 Key: OFBIZ-13000
 URL: https://issues.apache.org/jira/browse/OFBIZ-13000
 Project: OFBiz
  Issue Type: Sub-task
  Components: order
Affects Versions: Upcoming Branch
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


This Jira intend to fix order component groovy integration tests : 

 

2024-04-05 10:33:06,331 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.order.OrderTests
2024-04-05 10:33:06,332 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.order.OrderReturnTests
2024-04-05 10:33:06,334 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.order.OrderRequirementTests
2024-04-05 10:33:06,366 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.order.TestCustRequestPermissionCheck
2024-04-05 10:33:06,382 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.order.QuoteTests
2024-04-05 10:33:06,400 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.order.ShoppingListTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12998) Fix Partymgr Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12998.

Resolution: Fixed

[https://ci2.apache.org/#/builders/46/builds/785] OK

> Fix Partymgr Groovy tests
> -
>
> Key: OFBIZ-12998
> URL: https://issues.apache.org/jira/browse/OFBIZ-12998
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Upcoming Branch
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
>
> This Jira intend to fix party component groovy integration tests : 
> 2024-04-05 14:12:56,111 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.party.PartyTests
> 2024-04-05 14:12:56,125 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.ContactMechWorkerTests
> 2024-04-05 14:12:56,126 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyContactMechTests
> 2024-04-05 14:12:56,134 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyStatusChangeTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12999) Fix Product Groovy tests

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12999:


 Summary: Fix Product Groovy tests
 Key: OFBIZ-12999
 URL: https://issues.apache.org/jira/browse/OFBIZ-12999
 Project: OFBiz
  Issue Type: Sub-task
  Components: product
Affects Versions: Upcoming Branch
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


This Jira intend to fix product component groovy integration tests : 

2024-04-05 10:33:05,904 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.ProductPriceTests
2024-04-05 10:33:05,906 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.CategoryTests
2024-04-05 10:33:05,921 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.InventoryTests
2024-04-05 10:33:05,923 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.ShipmentTests
2024-04-05 10:33:05,939 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.CostTests
2024-04-05 10:33:05,960 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.ProductTagTest
2024-04-05 10:33:05,973 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.ProductTest
2024-04-05 10:33:05,975 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.product.ProductTests
2024-04-05 10:33:05,976 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.product.ProductFeatureTypeTests
2024-04-05 10:33:05,991 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.product.ProductPromoCondTests
2024-04-05 10:33:05,995 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.product.ProductPromoActionTests
2024-04-05 10:33:06,013 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.product.ProductConfigTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12985) Integration Groovy tests fail

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834313#comment-17834313
 ] 

Gil Portenseigne commented on OFBIZ-12985:
--

One thing is bothering me, we are putting integration test code into 
src/main/groovy, with a package name that do not contain "test" keyword. Only 
the file name indicates that is is test. 
I think we should if possible add test in package like it is done for some 
others like : InventoryItemTransferTest. 
I will test it with party tests, if ok, will continue the components like that.

> Integration Groovy tests fail
> -
>
> Key: OFBIZ-12985
> URL: https://issues.apache.org/jira/browse/OFBIZ-12985
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS, ALL PLUGINS
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: Upcoming Branch
>
>
> Groovy testIntegration, tests suites and tests cases no longer work
> For my own help here is a simple case to test
> bq. "ofbiz --test component=accounting --test suitename=invoicetests --test 
> testcase=invoice-per-shipment-tests"
> It seems testIntegrations work but when you look at the log you find a lot of 
> (46, barely same than number of files: 44, did not digg more) "Unable to load 
> test suite class" errors like this 1st one:
> {noformat} 
> |ModelTestSuite|E|Unable to load test suite class : 
> org.apache.ofbiz.party.PartyTests|
> {noformat} 
> You can find that in last ofbizTrunkFrameworkPlugins BB build: 
> [https://ci2.apache.org/#/builders/46/builds/777]
> The result seems successful. It's a misleading testIntegration result (not 
> sure what does that) and an already old one. TestIntegrations still work in 
> 18.12 and the issue is somehow related to OFBIZ-12813.
> It's a really confusing situation. Several issues prevent Groovy tests to 
> work.
> The reason is due to wrong Groovy tests package names and locations due to 
> OFBIZ-12813
> If we refer to our way of naming packages they are correctly referenced in 
> testdef (eg org.apache.ofbiz.accounting vs org.apache.accounting.accounting)
> So it's only a simple packages names and locations changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (OFBIZ-12998) Fix Partymgr Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne reassigned OFBIZ-12998:


Assignee: Gil Portenseigne

> Fix Partymgr Groovy tests
> -
>
> Key: OFBIZ-12998
> URL: https://issues.apache.org/jira/browse/OFBIZ-12998
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Upcoming Branch
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
>
> This Jira intend to fix party component groovy integration tests : 
> 2024-04-05 14:12:56,111 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.party.PartyTests
> 2024-04-05 14:12:56,125 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.ContactMechWorkerTests
> 2024-04-05 14:12:56,126 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyContactMechTests
> 2024-04-05 14:12:56,134 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyStatusChangeTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12998) Fix Partymgr Groovy tests

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12998:
-
Priority: Major  (was: Blocker)

> Fix Partymgr Groovy tests
> -
>
> Key: OFBIZ-12998
> URL: https://issues.apache.org/jira/browse/OFBIZ-12998
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Upcoming Branch
>Reporter: Gil Portenseigne
>Priority: Major
>
> This Jira intend to fix party component groovy integration tests : 
> 2024-04-05 14:12:56,111 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : org.apache.ofbiz.party.PartyTests
> 2024-04-05 14:12:56,125 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.ContactMechWorkerTests
> 2024-04-05 14:12:56,126 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyContactMechTests
> 2024-04-05 14:12:56,134 |main                 |ModelTestSuite                
> |E| Unable to load test suite class : 
> org.apache.ofbiz.party.PartyStatusChangeTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12998) Fix Partymgr Groovy tests

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12998:


 Summary: Fix Partymgr Groovy tests
 Key: OFBIZ-12998
 URL: https://issues.apache.org/jira/browse/OFBIZ-12998
 Project: OFBiz
  Issue Type: Sub-task
  Components: party
Affects Versions: Upcoming Branch
Reporter: Gil Portenseigne


This Jira intend to fix party component groovy integration tests : 

2024-04-05 14:12:56,111 |main                 |ModelTestSuite                
|E| Unable to load test suite class : org.apache.ofbiz.party.PartyTests
2024-04-05 14:12:56,125 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.party.ContactMechWorkerTests
2024-04-05 14:12:56,126 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.party.PartyContactMechTests
2024-04-05 14:12:56,134 |main                 |ModelTestSuite                
|E| Unable to load test suite class : 
org.apache.ofbiz.party.PartyStatusChangeTests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12985) Integration Groovy tests fail

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834249#comment-17834249
 ] 

Gil Portenseigne commented on OFBIZ-12985:
--

ow, sorry, i look that this afternoon

> Integration Groovy tests fail
> -
>
> Key: OFBIZ-12985
> URL: https://issues.apache.org/jira/browse/OFBIZ-12985
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS, ALL PLUGINS
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: Upcoming Branch
>
>
> Groovy testIntegration, tests suites and tests cases no longer work
> For my own help here is a simple case to test
> bq. "ofbiz --test component=accounting --test suitename=invoicetests --test 
> testcase=invoice-per-shipment-tests"
> It seems testIntegrations work but when you look at the log you find a lot of 
> (46, barely same than number of files: 44, did not digg more) "Unable to load 
> test suite class" errors like this 1st one:
> {noformat} 
> |ModelTestSuite|E|Unable to load test suite class : 
> org.apache.ofbiz.party.PartyTests|
> {noformat} 
> You can find that in last ofbizTrunkFrameworkPlugins BB build: 
> [https://ci2.apache.org/#/builders/46/builds/777]
> The result seems successful. It's a misleading testIntegration result (not 
> sure what does that) and an already old one. TestIntegrations still work in 
> 18.12 and the issue is somehow related to OFBIZ-12813.
> It's a really confusing situation. Several issues prevent Groovy tests to 
> work.
> The reason is due to wrong Groovy tests package names and locations due to 
> OFBIZ-12813
> If we refer to our way of naming packages they are correctly referenced in 
> testdef (eg org.apache.ofbiz.accounting vs org.apache.accounting.accounting)
> So it's only a simple packages names and locations changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12985) Integration Groovy tests fail

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12985.

Resolution: Fixed

Closing since last buildbot is ok. Thanks Jacques !

> Integration Groovy tests fail
> -
>
> Key: OFBIZ-12985
> URL: https://issues.apache.org/jira/browse/OFBIZ-12985
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS, ALL PLUGINS
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: Upcoming Branch
>
>
> Groovy testIntegration, tests suites and tests cases no longer work
> For my own help here is a simple case to test
> bq. "ofbiz --test component=accounting --test suitename=invoicetests --test 
> testcase=invoice-per-shipment-tests"
> It seems testIntegrations work but when you look at the log you find a lot of 
> (46, barely same than number of files: 44, did not digg more) "Unable to load 
> test suite class" errors like this 1st one:
> {noformat} 
> |ModelTestSuite|E|Unable to load test suite class : 
> org.apache.ofbiz.party.PartyTests|
> {noformat} 
> You can find that in last ofbizTrunkFrameworkPlugins BB build: 
> [https://ci2.apache.org/#/builders/46/builds/777]
> The result seems successful. It's a misleading testIntegration result (not 
> sure what does that) and an already old one. TestIntegrations still work in 
> 18.12 and the issue is somehow related to OFBIZ-12813.
> It's a really confusing situation. Several issues prevent Groovy tests to 
> work.
> The reason is due to wrong Groovy tests package names and locations due to 
> OFBIZ-12813
> If we refer to our way of naming packages they are correctly referenced in 
> testdef (eg org.apache.ofbiz.accounting vs org.apache.accounting.accounting)
> So it's only a simple packages names and locations changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12995) Fix Accounting Groovy tests

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834219#comment-17834219
 ] 

Gil Portenseigne commented on OFBIZ-12995:
--

Hi Jacques, do you need some help ? I'll have a look, if that is ok for you :)

> Fix Accounting Groovy tests
> ---
>
> Key: OFBIZ-12995
> URL: https://issues.apache.org/jira/browse/OFBIZ-12995
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> As mentionned in OFBIZ-12985 after OFBIZ-12813 the Groovy tests fail.
> There are severtal aspects, at least for now:
> #  structures (folders used and references to them);
> #  compilation (since OFBIZ-11165 Groovy tests must be compiled);
> #  migration from XML to Groovy specific errors
> About point 1 and 2, it turns out to be that the folders used don't allow 
> compilation.
> So, unlike unit tests ModelServiceTest.groovy, TestServices.groovy and 
> FileUtilTests.groovy put in sourcesets/test, integration tests must be in 
> sourcesets/main folders. Their references should be changed too.
> This is a subtask for the accounting component. The only changes are to move 
> Groovy tests to main and to accordingly change the references in 
> applications/accounting/testdef/ files.
> This fixes the inability to find the files where they are expected. Remains 
> few issues related to the point 3.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12963) Fix problems with Eclipse about multi module dependencies.

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830919#comment-17830919
 ] 

Gil Portenseigne commented on OFBIZ-12963:
--

Thanks Jacques, idea licence trolled me, so i decided to give this old fellow a 
try :), and indeed it seems better than in my memory.

About the navigator leila gave me this link : 
[https://stackoverflow.com/questions/60962386/why-is-eclipse-removing-the-navigator-view/65941171#65941171]
 to get a 'navigator like' behavior in Project Explorer.

> Fix problems with Eclipse about multi module dependencies.
> --
>
> Key: OFBIZ-12963
> URL: https://issues.apache.org/jira/browse/OFBIZ-12963
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-12963.patch
>
>
> On my journey to come back using Eclipse, i got some issues when loading 
> trunk :
> The package xxx is accessible from more than one module.
> This kind of issue appear when a project bring a dependency that is already 
> in another module in OFBiz
> The patch avoid loading 'pull-parser' and 'xpp3' dependencies that are 
> already present in jdk17.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12963) Fix problems with Eclipse about multi module dependencies.

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12963:
-
Attachment: OFBIZ-12963.patch

> Fix problems with Eclipse about multi module dependencies.
> --
>
> Key: OFBIZ-12963
> URL: https://issues.apache.org/jira/browse/OFBIZ-12963
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-12963.patch
>
>
> On my journey to come back using Eclipse, i got some issues when loading 
> trunk :
> The package xxx is accessible from more than one module.
> This kind of issue appear when a project bring a dependency that is already 
> in another module in OFBiz
> The patch avoid loading 'pull-parser' and 'xpp3' dependencies that are 
> already present in jdk17.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12963) Fix problems with Eclipse about multi module dependencies.

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12963:


 Summary: Fix problems with Eclipse about multi module dependencies.
 Key: OFBIZ-12963
 URL: https://issues.apache.org/jira/browse/OFBIZ-12963
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Upcoming Branch
Reporter: Gil Portenseigne


On my journey to come back using Eclipse, i got some issues when loading trunk :

The package xxx is accessible from more than one module.

This kind of issue appear when a project bring a dependency that is already in 
another module in OFBiz

The patch avoid loading 'pull-parser' and 'xpp3' dependencies that are already 
present in jdk17.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12940) Modal title not supported on hyperlink in form fields

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828921#comment-17828921
 ] 

Gil Portenseigne commented on OFBIZ-12940:
--

Hi Jacques, i got interrupted while doing it, i wanted to check for rel18 but 
not sure we'll do release :). So yes i close.

 

> Modal title not supported on hyperlink in form fields
> -
>
> Key: OFBIZ-12940
> URL: https://issues.apache.org/jira/browse/OFBIZ-12940
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 22.01.01, 18.12.12, 18.12.13
>Reporter: Florian Motteau
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: image-2024-03-14-08-58-13-835.png
>
>
> Hyperlinks elements can trigger the opening of a modal window 
> (link-type="layered-modal"). OFBiz uses jQuery UI Dialog to achieve this, and 
> parameters for this library are passed through a set of data-dialog-* ** 
> attributes on the "a" tag, in "HtmlFormMacroLibrary::makeHyperlinkString" 
> Freemarker macro. Then in OfbizUtil.js, links that should open modals are 
> processed : data-dialog-* are used to configure jQueryUI Dialog module.
>  
> In OfbizUtil.js, data-dialog-text attribute is used to set the title of the 
> modal (text in the colored top bar). The value of this attribute is set using 
> the "text" parameter in  "makeHyperlinkString" macro. However, this macro 
> does not declare a "text" parameter in its signature, and 
> HtmlMacroFormRenderer::makeHyperlinkString does not support it.
>  As a result, we cannot set the modal title when using a `hyperlink` tag  
> with a `text` attribute in a form (although the code indicates otherwise).
> !image-2024-03-14-08-58-13-835.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12940) Modal title not supported on hyperlink in form fields

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12940.

Resolution: Fixed

> Modal title not supported on hyperlink in form fields
> -
>
> Key: OFBIZ-12940
> URL: https://issues.apache.org/jira/browse/OFBIZ-12940
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 22.01.01, 18.12.12, 18.12.13
>Reporter: Florian Motteau
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: image-2024-03-14-08-58-13-835.png
>
>
> Hyperlinks elements can trigger the opening of a modal window 
> (link-type="layered-modal"). OFBiz uses jQuery UI Dialog to achieve this, and 
> parameters for this library are passed through a set of data-dialog-* ** 
> attributes on the "a" tag, in "HtmlFormMacroLibrary::makeHyperlinkString" 
> Freemarker macro. Then in OfbizUtil.js, links that should open modals are 
> processed : data-dialog-* are used to configure jQueryUI Dialog module.
>  
> In OfbizUtil.js, data-dialog-text attribute is used to set the title of the 
> modal (text in the colored top bar). The value of this attribute is set using 
> the "text" parameter in  "makeHyperlinkString" macro. However, this macro 
> does not declare a "text" parameter in its signature, and 
> HtmlMacroFormRenderer::makeHyperlinkString does not support it.
>  As a result, we cannot set the modal title when using a `hyperlink` tag  
> with a `text` attribute in a form (although the code indicates otherwise).
> !image-2024-03-14-08-58-13-835.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12940) Modal title not supported on hyperlink in form fields

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12940:
-
Fix Version/s: Upcoming Branch

> Modal title not supported on hyperlink in form fields
> -
>
> Key: OFBIZ-12940
> URL: https://issues.apache.org/jira/browse/OFBIZ-12940
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 22.01.01, 18.12.12, 18.12.13
>Reporter: Florian Motteau
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: image-2024-03-14-08-58-13-835.png
>
>
> Hyperlinks elements can trigger the opening of a modal window 
> (link-type="layered-modal"). OFBiz uses jQuery UI Dialog to achieve this, and 
> parameters for this library are passed through a set of data-dialog-* ** 
> attributes on the "a" tag, in "HtmlFormMacroLibrary::makeHyperlinkString" 
> Freemarker macro. Then in OfbizUtil.js, links that should open modals are 
> processed : data-dialog-* are used to configure jQueryUI Dialog module.
>  
> In OfbizUtil.js, data-dialog-text attribute is used to set the title of the 
> modal (text in the colored top bar). The value of this attribute is set using 
> the "text" parameter in  "makeHyperlinkString" macro. However, this macro 
> does not declare a "text" parameter in its signature, and 
> HtmlMacroFormRenderer::makeHyperlinkString does not support it.
>  As a result, we cannot set the modal title when using a `hyperlink` tag  
> with a `text` attribute in a form (although the code indicates otherwise).
> !image-2024-03-14-08-58-13-835.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (OFBIZ-12940) Modal title not supported on hyperlink in form fields

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne reassigned OFBIZ-12940:


Assignee: Gil Portenseigne

> Modal title not supported on hyperlink in form fields
> -
>
> Key: OFBIZ-12940
> URL: https://issues.apache.org/jira/browse/OFBIZ-12940
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 22.01.01, 18.12.12, 18.12.13
>Reporter: Florian Motteau
>Assignee: Gil Portenseigne
>Priority: Major
> Attachments: image-2024-03-14-08-58-13-835.png
>
>
> Hyperlinks elements can trigger the opening of a modal window 
> (link-type="layered-modal"). OFBiz uses jQuery UI Dialog to achieve this, and 
> parameters for this library are passed through a set of data-dialog-* ** 
> attributes on the "a" tag, in "HtmlFormMacroLibrary::makeHyperlinkString" 
> Freemarker macro. Then in OfbizUtil.js, links that should open modals are 
> processed : data-dialog-* are used to configure jQueryUI Dialog module.
>  
> In OfbizUtil.js, data-dialog-text attribute is used to set the title of the 
> modal (text in the colored top bar). The value of this attribute is set using 
> the "text" parameter in  "makeHyperlinkString" macro. However, this macro 
> does not declare a "text" parameter in its signature, and 
> HtmlMacroFormRenderer::makeHyperlinkString does not support it.
>  As a result, we cannot set the modal title when using a `hyperlink` tag  
> with a `text` attribute in a form (although the code indicates otherwise).
> !image-2024-03-14-08-58-13-835.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803598#comment-17803598
 ] 

Gil Portenseigne commented on OFBIZ-12726:
--

Thanks and nice catch, I agree we can close with creating a ticket to not 
forget the issue with xstream.

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png, image-2024-01-04-18-27-42-512.png, 
> image-2024-01-04-18-28-27-910.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795857#comment-17795857
 ] 

Gil Portenseigne commented on OFBIZ-12726:
--

Hello Eugen, Jacques,

I just join the effort, removing 
{{{}'--add-opens=java.base/java.util=ALL-UNNAMED'{}}}, i also got the errors.

But using :
{code:java}
./gradlew "ofbiz --test component=order "
./gradlew "ofbiz --test component=minilang " {code}
Make the failing tests pass...  there seems to have an dependency between the 
tests, with one error somewhere in test or between. I will continue to 
investigate on Friday.

For accounting : 
!image-2023-12-12-18-10-16-016.png!

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12726) Running integration tests under Gradle 7.6 and JDK 17 fails

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12726:
-
Attachment: image-2023-12-12-18-10-16-016.png

> Running integration tests under Gradle 7.6 and JDK 17 fails
> ---
>
> Key: OFBIZ-12726
> URL: https://issues.apache.org/jira/browse/OFBIZ-12726
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: 22.01.01
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Blocker
> Attachments: image-2023-12-05-16-52-38-822.png, 
> image-2023-12-12-18-10-16-016.png
>
>
> Following our discussion at 
> https://lists.apache.org/thread/kr4v21lxx493byzgpdrzfbz3whhbm82m I ran the 
> integration tests and found that we currently have 322 errors and 190 
> failures :/ 
> It's a blocker for releasing...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache OFBiz 18.12.10

[Gil Portenseigne]

+1

Thanks,

Gil

On 27/11/2023 11:48, Jacopo Cappellato wrote:

This is the vote thread to publish "Apache OFBiz 18.12.10", tenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.10.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.10.zip.asc: the detached signature file
* apache-ofbiz-18.12.10.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.10
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

[jira] [Commented] (OFBIZ-10213) Update build.gradle to the latest dependencies

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755986#comment-17755986
 ] 

Gil Portenseigne commented on OFBIZ-10213:
--

Hello [~jleroux] , i just made some manual updates, then discovered this jira.
I will start to generate a new patch to update dependencies.

> Update build.gradle to the latest dependencies
> --
>
> Key: OFBIZ-10213
> URL: https://issues.apache.org/jira/browse/OFBIZ-10213
> Project: OFBiz
>  Issue Type: Task
>  Components: Gradle
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Jacques Le Roux
>Priority: Trivial
> Attachments: OFBIZ-10213.patch, OFBIZ-10213.patch, OFBIZ-10213.patch
>
>
> h2. This is an umbrella task for its action subtasks, please do not close, 
> thanks.
> We want to check from time to time if we need to update the dependencies.
> It's easily done with the [gradle-versions-plugin 
> |https://github.com/ben-manes/gradle-versions-plugin] which analyzes the 
> dependencies and checks if there are newer versions available.
> Running the check with
> {code:java}
> gradlew -PenableDependencyUpdates dependencyUpdates -Drevision=release
> {code}
> We get a list of dependencies to update.
> We have problems with a number of libs. We keep comments in the main 
> build.gradle for special updating issues. Be sure to check the main 
> build.gradle. Some Java classes need internal versions update too:
> Also Solr et Lucene should use the same version, luceneMatchVersion should be 
> updated in solrconfig.xml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12844) Update zip4j to 2.11.5

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12844.

Fix Version/s: 22.01.01
   Upcoming Branch
   Resolution: Fixed

> Update zip4j to 2.11.5
> --
>
> Key: OFBIZ-12844
> URL: https://issues.apache.org/jira/browse/OFBIZ-12844
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: 22.01.01
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Major
> Fix For: 22.01.01, Upcoming Branch
>
>
> See [https://github.com/srikanth-lingala/zip4j/releases]
> Current 2.11.2 need update to fix CVE



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12845) Update commons-net to 3.9.0

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12845:


 Summary: Update commons-net to 3.9.0
 Key: OFBIZ-12845
 URL: https://issues.apache.org/jira/browse/OFBIZ-12845
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: 22.01.01
Reporter: Gil Portenseigne
 Fix For: Upcoming Branch


Update to last current release fixing 
[CVE-2021-37533|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37533]

https://lists.apache.org/thread/vys2q39lrkyqcyr7rhj9308c4rpq8kkm



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (NET-724) Update commons-net to

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/NET-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed NET-724.


> Update commons-net to 
> --
>
> Key: NET-724
> URL: https://issues.apache.org/jira/browse/NET-724
> Project: Commons Net
>  Issue Type: Improvement
>    Reporter: Gil Portenseigne
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (NET-724) Update commons-net to

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/NET-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne resolved NET-724.
--
Resolution: Abandoned

Sorry, ticket was created by mistake.

> Update commons-net to 
> --
>
> Key: NET-724
> URL: https://issues.apache.org/jira/browse/NET-724
> Project: Commons Net
>  Issue Type: Improvement
>    Reporter: Gil Portenseigne
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NET-724) Update commons-net to

[Gil Portenseigne (Jira)]

Gil Portenseigne created NET-724:


 Summary: Update commons-net to 
 Key: NET-724
 URL: https://issues.apache.org/jira/browse/NET-724
 Project: Commons Net
  Issue Type: Improvement
Reporter: Gil Portenseigne






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12844) Update zip4j to 2.11.5

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12844:


 Summary: Update zip4j to 2.11.5
 Key: OFBIZ-12844
 URL: https://issues.apache.org/jira/browse/OFBIZ-12844
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: 22.01.01
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


See [https://github.com/srikanth-lingala/zip4j/releases]
Current 2.11.2 need update to fix CVE



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

IDEA plugin contribution

[Gil Portenseigne]

Hello,

I'm starting a new thread to get your opinion about contributing the 
OFBiz idea plugin.


This intention was already done in the past in 
https://lists.apache.org/thread/03fr40tvhkv97pqrgt4nl78w4m6ml33w , but 
no conclusion was made.


Gaëtan continued working on the plugin to provide more and more 
features, last one was about inspection of file references through 
`component://` notation.


Other features from the top of my head are :
* field completion in view and entity for declared GenericValue
* Completion in DynamicView system
* widget navigation in standard screens, and more recently in compound
* service name completion in runSync and navigation
* entity name completion in EntityQuery usage and navigation
* POC hover documentation

I totally agree with the last message from Michael in the existing 
thread, and we started to work on Apache standards in : 
https://github.com/Nereide-lab/idea-ofbiz-plugin/tree/apache-standardisation


If the idea pleases the community, i will be happy to set up the new 
repository and procedure for plugin release and so on. I will just need 
some guidance on the best way to do it.


Thanks and regards,

Gil

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

Hello,

Reading this i discussed with Gaëtan about somthing that could help control 
that every groovyScript reference in Screens/Forms/Services are effectively 
referencing an existing file.

As you might know, Gaëtan is contributing an IDEA plugin dedicated to OFBiz [1].
The plugin already manage component:// notation, that allow highlighting of 
missing referenced file in editor.

We discussed about inspection feature, that could detect bad references for 
groovyScript (and others) files. Whereas he is not familiar with IDEA 
inspection feature in the plugin, we could try to start building one for this 
particular effort, if that could bring more confidence in migration.

Regards,

Gil
 
[1] https://lists.apache.org/thread/03fr40tvhkv97pqrgt4nl78w4m6ml33w  

On 2023/05/02 07:16:35 Daniel Watford wrote:
> Hi Michael,
> 
> I would be concerned about our capacity to move all these groovy scripts
> and ensure correct location updates are made to the  path="..." /> elements in the controller.xml files and  engine="groovy" location="..." .../> elements in service definitions in
> both trunk and the release22.01 branch.
> 
> If we were to pursue these changes, could we add a test mode to code that
> parses service definitions and controller xml files to check that the
> groovy location (and invoked methods were relevant) are accessible? This
> means we would have some automation to help ensure changes have been
> applied correctly.
> 
> This will be a big undertaking, so I would suggest creating some
> mini-project-management similar to that done for the CodeNarc integration
> where we have a list of files that need moving and committers add their
> name to files they are actively working on. I would also request that we
> introduce rules for this mini-project such as, 'No functional changes to
> code', and 'keep Pull Requests small', etc.
> 
> To answer your original question, if we do not make the proposed changes to
> release 22.01, we will substantially degrade the ability for developers
> using Eclipse to work with OFBiz. But if we do proceed with this work, we
> will effectively need to do it twice - once for the release22.01 branch and
> once for trunk - a pretty heavy undertaking.
> 
> On balance I think it would be bad for the project to release OFBiz in a
> state which is difficult for developers/system integrators to work with, so
> we MUST ensure OFBiz is 'debuggable'.
> 
> I'll ask one more question (and then run for cover!): Rather than carry out
> this work twice.  What if we abandon the 22.01 release and instead make a
> new release branch (23.xx) soon after moving the Groovy sources?
> 
> Thanks,
> 
> Dan.
> 
> On Wed, 26 Apr 2023 at 12:23, Michael Brohl 
> wrote:
> 
> > Hi,
> >
> > I suggest to start with a new ticket to coordinate the refactoring work
> > (will you take this into your hands, Wiebke?).
> >
> > OFBIZ-10226 has another intention which will not solve the overall
> > problem Wiebke described.
> >
> > Does the community agree that we'll have to do this work?
> >
> > Even more, do we agree that it has to be done before we can ship a first
> > 22.01 release based on JDK 17?
> >
> > Best regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 25.04.23 um 18:30 schrieb Jacques Le Roux:
> > > Thanks Wiebke,
> > >
> > > I know that for a while (https://s.apache.org/kewrn) but was
> > > desperately trying to avoid what you propose. It's indeed the right
> > > solution.
> > >
> > > So I think we can go on with OFBIZ-10226. At the bottom there is a
> > > link to a related discussion with some opinions from then. Or do you
> > > prefer to start anew for the sake of clarity?
> > >
> > > Thanks again for your work, I was not aware of this Groovy page. It
> > > definitely confirms what Mathieu said then.
> > >
> > > Jacques
> > >
> > > Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :
> > >> Hi everyone,
> > >>
> > >> I did a bit of research regarding the groovy debugging.
> > >> After some research I found this:
> > >>
> > >> “The Java Platform Module System requires that classes in distinct
> > >> modules have distinct package names. Groovy has its own "modules" but
> > >> these haven’t historically been structured according to the above
> > >> requirement. For this reason, Groovy 2.x and 3.0 should be added to
> > >> the classpath not module path when using JDK9+. This places Groovy’s
> > >> classes into the unnamed module where the split package naming
> > >> requirement is not enforced.“
> > >>
> > http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages
> > >>
> > >>
> > >> For testing I used the service "sendEmailDated" in
> > >> CommunicationEventServices.groovy. I can confirm the described
> > >> behavior of Jacques, without a package declaration the service does
> > >> not stop at my breakpoint. If I add the package declaration for the
> > >> class, the service stops at my breakpoint.
> > >>
> > >> From my point of view it 

[jira] [Closed] (OFBIZ-12816) Fix exception for createFuturePeriod Service

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12816.

Resolution: Fixed

> Fix exception for createFuturePeriod Service
> 
>
> Key: OFBIZ-12816
> URL: https://issues.apache.org/jira/browse/OFBIZ-12816
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Trivial
> Fix For: Upcoming Branch
>
>
> Exception is thrown when using createFuturePeriod service :
> {code:java}
>  org.apache.ofbiz.entity.transaction.GenericTransactionException: Roll back 
> error, could not commit transaction, was rolled back instead because of: 
> Service [createFuturePeriod] threw an unexpected 
> exception/errororg.apache.ofbiz.service.GenericServiceException: Error 
> running Groovy method [createFuturePeriod] in Groovy file 
> [component://common/groovyScripts/CommonServices.groovy]:  (Error while 
> checking to see if this is the last result (The 'isLast' method is only 
> allowed on scroll cursors.)) (Error running Groovy method 
> [createFuturePeriod] in Groovy file 
> [component://common/groovyScripts/CommonServices.groovy]:  (Error while 
> checking to see if this is the last result (The 'isLast' method is only 
> allowed on scroll cursors.)))
> {code}
> Indeed `hasNext` is used on `EntityListIterator`, this usage is discourage in 
> its javadoc displaying a warning and leading to this exception.
> A simple fix is to not test next value presence before getting it, but after..



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12816) Fix exception for createFuturePeriod Service

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12816:


 Summary: Fix exception for createFuturePeriod Service
 Key: OFBIZ-12816
 URL: https://issues.apache.org/jira/browse/OFBIZ-12816
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Upcoming Branch
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne
 Fix For: Upcoming Branch


Exception is thrown when using createFuturePeriod service :
{code:java}
 org.apache.ofbiz.entity.transaction.GenericTransactionException: Roll back 
error, could not commit transaction, was rolled back instead because of: 
Service [createFuturePeriod] threw an unexpected 
exception/errororg.apache.ofbiz.service.GenericServiceException: Error running 
Groovy method [createFuturePeriod] in Groovy file 
[component://common/groovyScripts/CommonServices.groovy]:  (Error while 
checking to see if this is the last result (The 'isLast' method is only allowed 
on scroll cursors.)) (Error running Groovy method [createFuturePeriod] in 
Groovy file [component://common/groovyScripts/CommonServices.groovy]:  (Error 
while checking to see if this is the last result (The 'isLast' method is only 
allowed on scroll cursors.)))
{code}
Indeed `hasNext` is used on `EntityListIterator`, this usage is discourage in 
its javadoc displaying a warning and leading to this exception.

A simple fix is to not test next value presence before getting it, but after..



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-12801) Error at CommunicationEventServices.groovy:489 due to OFBIZ-11167

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12801.

Resolution: Fixed

> Error at  CommunicationEventServices.groovy:489 due to OFBIZ-11167
> --
>
> Key: OFBIZ-12801
> URL: https://issues.apache.org/jira/browse/OFBIZ-12801
> Project: OFBiz
>  Issue Type: Bug
>  Components: projectmgr
>Affects Versions: Upcoming Branch
> Environment: 
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> I get this error locally:
> The Following Errors Occurred:
> Service dispatcher threw an exception:Error running Groovy method 
> [sendEmailDated] in Groovy file 
> [component://party/groovyScripts/communication/CommunicationEventServices.groovy]:
>  (Cannot cast object '[]' with class 'java.util.ArrayList' to class 
> 'java.util.Map' due to: groovy.lang.GroovyRuntimeException: Could not find 
> matching constructor for: java.util.Map())
> When I replace 
> Map sendEmailDated() {
> by
> def sendEmailDated() {
> The error disappears
> I guess something better can be done, but I have not yet found what :)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

+1

Thanks,

Gil

Le 03/05/2023 à 16:39, Michael Brohl a écrit :

+1 from my side.

Best regards,

Michael


Am 03.05.23 um 09:45 schrieb Jacopo Cappellato:

On Tue, May 2, 2023 at 9:17 AM Daniel Watford  wrote:
[...]
I'll ask one more question (and then run for cover!): Rather than 
carry out
this work twice.  What if we abandon the 22.01 release and instead 
make a

new release branch (23.xx) soon after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

[jira] [Commented] (OFBIZ-12801) Error at CommunicationEventServices.groovy:489 due to OFBIZ-11167

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719844#comment-17719844
 ] 

Gil Portenseigne commented on OFBIZ-12801:
--

Hello Jacques, Daniel,

While the discussion continue about GroovyBaseScript in dev mailing list, i 
think we can agree for this case to move the return success() out of the each 
block ?

Thanks,

Gil

> Error at  CommunicationEventServices.groovy:489 due to OFBIZ-11167
> --
>
> Key: OFBIZ-12801
> URL: https://issues.apache.org/jira/browse/OFBIZ-12801
> Project: OFBiz
>  Issue Type: Bug
>  Components: projectmgr
>Affects Versions: Upcoming Branch
> Environment: 
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> I get this error locally:
> The Following Errors Occurred:
> Service dispatcher threw an exception:Error running Groovy method 
> [sendEmailDated] in Groovy file 
> [component://party/groovyScripts/communication/CommunicationEventServices.groovy]:
>  (Cannot cast object '[]' with class 'java.util.ArrayList' to class 
> 'java.util.Map' due to: groovy.lang.GroovyRuntimeException: Could not find 
> matching constructor for: java.util.Map())
> When I replace 
> Map sendEmailDated() {
> by
> def sendEmailDated() {
> The error disappears
> I guess something better can be done, but I have not yet found what :)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Gil Portenseigne]

Hello I got a quick look about it, having two separate class means 
having two distinct groovy DSL and need lot of modification that IMO are 
not worth the complexity for this subject.


I now only wonder, is it that bad too keep that one exception (about 
untyped return) for GroovyBaseScript::success ?


Gil

Le 26/04/2023 à 09:49, Gil Portenseigne a écrit :

Hello,

I like the idea that the developer do not have to sync about which 
method to use.


If I understand well what Michael envision, i.e. to use for event a 
new GroovyBaseEvent class, and for services/scripts a GroovyBaseScript 
class, that both extends a common class for the common code, should be 
one way to allow this usage.


But I don't know about IDE integration behavior of such a solution...

Do you think that is worth a look ?

I will just add that there is a chance that project implementation are 
using groovy script as the event target (I know some ;) )


Thanks,

Gil

Le 20/04/2023 à 17:13, Michael Brohl a écrit :
To have it even more clear, I would separate logic for events and 
services.


The GroovyBaseScript in the service engine package should only be 
used for services and there should be another one for events, if 
really needed. Mixing both together is bad practice IMO. There seem 
to be only 7 controller entries using a groovy script as the event 
target.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 16:49 schrieb Jacques Le Roux:

Hi Daniel,

I dont think there is a knowledge about methods being both services 
and events. I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log 
content (now in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available 
in Groovy 3)

that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated 
and replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly 
in scripts methods with the help of Codenarc, right ?


My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the 
code was

called.

The untyped nature of Groovy had allowed a certain degree of 
flexibility in

code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly 
driven by
increased use of linters/static analysers, we have seen a push back 
towards

explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need 
to avoid

the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, 
instead, a
groovy method should be intentionally written as either a service 
or event

handler.

If we have cases where a groovy method is used to provide 
implementations
for both a service and an event handler, then we can employ a thin 
adapter
layer to convert the result type between the two calling 
conventions. Do we

know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of 
GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and 
String

respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le 
Roux

wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and 
decide.


As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup

[Gil Portenseigne]

+1

Gil

Le 26/04/2023 à 16:36, Jacques Le Roux a écrit :

+1

Jacques

Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit :

+1

Jacopo

On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl 
 wrote:

Hi everyone,

any objections against merging those pr's for framework/plugins in
trunk/release22.01?

I think it would be good to test the changes on the demo servers as 
well

to detect possible runtime problems caused by the changed dependencies.

If there are no objections, I would like to merge the changes tomorrow.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira):
  [ 
https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714986#comment-17714986 
]


Michael Brohl commented on OFBIZ-12808:
---

Fixes for framework / plugins for trunk and release22.01 are now in 
the pull requests.


To test, the corresponding pr's for framework and plugins have to 
be checked out respectively.



Eclipse build problems and proper dependency setup
--

  Key: OFBIZ-12808
  URL: 
https://issues.apache.org/jira/browse/OFBIZ-12808

  Project: OFBiz
   Issue Type: Bug
   Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS
 Affects Versions: 22.01.01, Upcoming Branch
 Reporter: Michael Brohl
 Assignee: Michael Brohl
 Priority: Major
  Fix For: 22.01.01, Upcoming Branch


Due to improper dependency configurations and the JPMS (Java 
Plattform Module System) which was introduced to Java since 
version 9, the Eclipse build and running/debugging is not working 
with JDK 17 (trunk and release22.01).
The reason is that there are dependencies to libraries which are 
also shipped with the JDK which causes a conflict leading to 
ignore those packages/classes in the build.

We have a working solution for this.


--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Gil Portenseigne]

Hello,

I like the idea that the developer do not have to sync about which 
method to use.


If I understand well what Michael envision, i.e. to use for event a new 
GroovyBaseEvent class, and for services/scripts a GroovyBaseScript 
class, that both extends a common class for the common code, should be 
one way to allow this usage.


But I don't know about IDE integration behavior of such a solution...

Do you think that is worth a look ?

I will just add that there is a chance that project implementation are 
using groovy script as the event target (I know some ;) )


Thanks,

Gil

Le 20/04/2023 à 17:13, Michael Brohl a écrit :
To have it even more clear, I would separate logic for events and 
services.


The GroovyBaseScript in the service engine package should only be used 
for services and there should be another one for events, if really 
needed. Mixing both together is bad practice IMO. There seem to be 
only 7 controller entries using a groovy script as the event target.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 16:49 schrieb Jacques Le Roux:

Hi Daniel,

I dont think there is a knowledge about methods being both services 
and events. I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log 
content (now in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available 
in Groovy 3)

that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated and 
replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly 
in scripts methods with the help of Codenarc, right ?


My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the 
code was

called.

The untyped nature of Groovy had allowed a certain degree of 
flexibility in

code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly 
driven by
increased use of linters/static analysers, we have seen a push back 
towards

explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need 
to avoid

the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, instead, a
groovy method should be intentionally written as either a service or 
event

handler.

If we have cases where a groovy method is used to provide 
implementations
for both a service and an event handler, then we can employ a thin 
adapter
layer to convert the result type between the two calling 
conventions. Do we

know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of 
GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and 
String

respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le 
Roux

wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and 
decide.


As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

[jira] [Commented] (OFBIZ-12801) Error at CommunicationEventServices.groovy:489 due to OFBIZ-11167

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713934#comment-17713934
 ] 

Gil Portenseigne commented on OFBIZ-12801:
--

For this case I agree that the fix should be returning success at the end of 
the service implementation.

I personally wondered about success method that can return two different types 
depending of the context (request vs service), and I agree that any groovy 
script implementation using this method are only of one type.

But I think that this particular implementation was intentional to avoid the 
dev to think about being in service or event, and using success() in any 
situation. (same with error method).

Quote of the commit message from Jacopo :
{quote}these helper methods have been enhanced in order to be used by groovy 
method executed as services or events in a transparent way.
{quote}
With that intent in mind, codenarc-disable was set, i'm yet not sure that we 
should remove that intent, that technically do not cause any issue apart from 
having NoDef best practice not respected.

I guess that should be discussed in another Jira / mailing list :)

 

> Error at  CommunicationEventServices.groovy:489 due to OFBIZ-11167
> --
>
> Key: OFBIZ-12801
> URL: https://issues.apache.org/jira/browse/OFBIZ-12801
> Project: OFBiz
>  Issue Type: Bug
>  Components: projectmgr
>Affects Versions: Upcoming Branch
> Environment: 
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> I get this error locally:
> The Following Errors Occurred:
> Service dispatcher threw an exception:Error running Groovy method 
> [sendEmailDated] in Groovy file 
> [component://party/groovyScripts/communication/CommunicationEventServices.groovy]:
>  (Cannot cast object '[]' with class 'java.util.ArrayList' to class 
> 'java.util.Map' due to: groovy.lang.GroovyRuntimeException: Could not find 
> matching constructor for: java.util.Map())
> When I replace 
> Map sendEmailDated() {
> by
> def sendEmailDated() {
> The error disappears
> I guess something better can be done, but I have not yet found what :)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-11167) Use Codenarc to test Groovy code

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-11167.

Fix Version/s: 22.01.01
   Upcoming Branch
   Resolution: Implemented

> Use Codenarc to test Groovy code
> 
>
> Key: OFBIZ-11167
> URL: https://issues.apache.org/jira/browse/OFBIZ-11167
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
> Fix For: 22.01.01, Upcoming Branch
>
> Attachments: OFBIZ-11167.patch, main.html, test.html
>
>
> Thread of community discussion about the rules to implement : 
> https://www.mail-archive.com/search?l=dev%40ofbiz.apache.org=subject:%22Codenarc+integration%2C+rules+to+use.%22=newest=1
>  
> Now that we use Groovy more and more, I think we should really have a look a 
> Codenarc
> [https://docs.gradle.org/current/userguide/codenarc_plugin.html]
> We already discussed it at [https://markmail.org/message/uigcpnxqgizhd2oi] 
> and [https://markmail.org/message/rp6njoiohkkiodbe]
> We know it's a crucial task but not an easy but rather a long term one
> Here are some interesting links (before I delete my FF tabs group about it)
> [http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html]
> [http://codenarc.sourceforge.net/codenarc-creating-ruleset.html]
> [https://github.com/gradle/gradle/tree/master/config]
> [https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s]
> [https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Codenarc integration process

[Gil Portenseigne]

Hello !

I just squashed and committed the pull request, I would like to thank 
you again for the review work and animation !


I failed the commit message due to the pull request feature i was not 
familiar about...


I am not aware of "force push" policy in trunk that could allow me to 
fix that, i wanted to ask if it is allowed ?


Gil


Le 27/03/2023 à 16:46, Jacques Le Roux a écrit :

Hi Guys,

For those who have used a non "PASSED" lozenge in wiki and resolved a 
related conversation in GH please update the status in wiki


TIA

Jacques

Le 28/01/2023 à 11:51, Gil Portenseigne a écrit :

Oh sorry indeed i overview the review approach section.

The table is nice, thanks Dan !

28 janv. 2023 09:37:50 Daniel Watford :


Hi Gil,

I don't think a checklist is quite enough, assuming we want to track 
the

status of each file reviewed.

 From the review approach section:


    - If in the reviewers opinion a file change will not change OFBiz
    behaviour in any way they should mark the corresponding entry in 
the table

    below as PASSED.
    - If the reviewer identifies an issue with a changed file, then 
they
    should add a comment in the PR on GitHub AND mark the 
corresponding entry

    in the table below as WORK NEEDED.
    - If the reviewer is unsure how to classify a changed file they 
should

    mark the corresponding entry in the table below as UNSURE.
    - In each of the above cases, the reviewer should add their name 
against

    the entry in the table below.

The checklist doesn't give us the opportunity to see what files need 
some

additional help.

I'm sure there must be some way of getting Confluence to produce a 
table
from a list - I just don't seem to have found it yet! I'll play 
around with

Confluence a bit more.

But as mentioned before, perhaps I am making too much out of 
tracking this

review.

Thanks,

Dan.


On Fri, 27 Jan 2023 at 17:05, gil.portenseigne 


wrote:


I got to leave, but i generated in confluence a list of check, is that
good enough ?

Gil
On 27/01/23 05:41, gil.portenseigne wrote:
Hello, indeed, that will generate much spam, i did some before 
reading

your answer.

I'll have a look for conluence.

Gil


On 27/01/23 04:14, Daniel Watford wrote:

Hi Gill and Jacques,

I don't think we should add comments to the PR to track the files 
that

we

have reviewed as I think each comment will appear separately in the

PR's

conversation view.

However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.

I created a page here - Codenarc integration review tracker - OFBiz

Project

Open Wiki - Apache Software Foundation
<
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker 


-
suggesting an approach.

If the approach is acceptable then all reviewers should be able to

update

the page as we go.

I'm stuck with finding a nice way to generate a table listing all 
the
changed files and the review status of each file. I have included 
the

commands to produce the list of files and shown some examples of how

to add

a header, but my attempts to turn that into something useful on a
confluence page have not been fruitful.

So two questions.
- Is it worth coming up with a page/table to track this PR or am 
I just
creating unnecessary admin work when we could use comments in the 
PR?

- Can anyone create a table in Confluence that we could use to track

the

review effort?

Thanks,

Dan.


On Fri, 27 Jan 2023 at 15:27, gil.portenseigne <

gil.portensei...@nereide.fr>

wrote:


Oops, i did a fixup commit with push force that remove all comments

in

the pull request... Will not do that again.

I fixed the detected typo.

gil
On 27/01/23 02:56, Jacques Le Roux wrote:

…

the pull

…

checkbox if a

…

request,

…

to the

same conclusion.

…

Could

be easy if it's the same unique words in every file.

…

concern

one

…

but it

…

file, to

let

…

"Review
changes" button allows you to comment, approve or request 
changes on

this

file.

…

can

mark an

…

reviewers

can skip

…


--
Daniel Watford




--
Daniel Watford

Re: how to add multiple .ftl files in screen.xml based on user permissions using if else conditions

[Gil Portenseigne]

One way of doing that is to have a structure like


    
 
    
    
    One
    
    
   
    
                  permission="XERUS_ASSETMAINTENANCE"

action="_VIEW"/>
    
    
   two
    
    
                        default
    
    
    


That is not elegant.


Another way I prefer is to have a script that define the screen to 
render like :



    
    
    

Re: how to add multiple .ftl files in screen.xml based on user permissions using if else conditions

[Gil Portenseigne]

Hello Mahi,

You can find multiple examples in the code base looking for : 
``


One of :


    
    service-name="workEffortGenericPermission" main-action="VIEW"/>

    
    
    location="component://workeffort/template/task/MyTasks.ftl"/>

    
    
    style="h3">${uiLabelMap.WorkEffortViewPermissionError}

    


If condition is true, widgets will display, else that will be fail-widgets

Regards

Gil

Le 11/04/2023 à 09:08, Mahi maheshwari a écrit :

Hello Community,

I want to add .ftl files in screens.xml for multiple users based on a few
conditions if there are multiple users named production user and quality
user and other users, so for this users if I want to give permission for
viewing any .ftl files, how can I do it.

*for instance*, if production_user has permission to view only the
production module then render production.ftl ,  if quality_user has
permission to view only the quality module then render quality.ftl and if
assets_user has permission to view the assets module then render
assetmaint.ftl.
I want to give conditions like if else in one  tag in screens.xml

*example: *
in widgets/screens.xml

if(User has Production_View permission)
then

else if(User has AssetMaintaince_View permission)
then

else if(User has Quality_View permission)
then
 
else

END of if


please let me know how can I achieve this.


Best Regards,
Maheshwari.

Re: [VOTE] Apache OFBiz 18.12.07

[Gil Portenseigne]

+1

Everything is fine from my side !

Thanks

Gil

Le 03/04/2023 à 09:47, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.07", seventh
and probably final release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.07.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.07.zip.asc: the detached signature file
* apache-ofbiz-18.12.07.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.07
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

[jira] [Commented] (OFBIZ-9984) Convert OrderServices.xml mini-lang to groovyDSL

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17687808#comment-17687808
 ] 

Gil Portenseigne commented on OFBIZ-9984:
-

Hello Jacques, IIRW it was not complete, only partly done, as [~sberg] offers 
to continue the work, i stopped working on it and got on other subject. 

[~sberg] do you intent to continue ?

Thanks

Gil

> Convert OrderServices.xml mini-lang to groovyDSL
> 
>
> Key: OFBIZ-9984
> URL: https://issues.apache.org/jira/browse/OFBIZ-9984
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: order
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Julien NICOLAS
>    Assignee: Gil Portenseigne
>Priority: Minor
>  Labels: groovy, mini-lang
> Attachments: OFBIZ-9984-v1.patch, OFBIZ-9984.patch
>
>
> With the purpose to deprecate mini-lang OFBIZ-9350, I tried to convert some 
> mini-lang service to groovy script.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Codenarc integration process

[Gil Portenseigne]

Oh sorry indeed i overview the review approach section.

The table is nice, thanks Dan !

28 janv. 2023 09:37:50 Daniel Watford :

> Hi Gil,
> 
> I don't think a checklist is quite enough, assuming we want to track the
> status of each file reviewed.
> 
> From the review approach section:
> 
> 
>    - If in the reviewers opinion a file change will not change OFBiz
>    behaviour in any way they should mark the corresponding entry in the table
>    below as PASSED.
>    - If the reviewer identifies an issue with a changed file, then they
>    should add a comment in the PR on GitHub AND mark the corresponding entry
>    in the table below as WORK NEEDED.
>    - If the reviewer is unsure how to classify a changed file they should
>    mark the corresponding entry in the table below as UNSURE.
>    - In each of the above cases, the reviewer should add their name against
>    the entry in the table below.
> 
> The checklist doesn't give us the opportunity to see what files need some
> additional help.
> 
> I'm sure there must be some way of getting Confluence to produce a table
> from a list - I just don't seem to have found it yet! I'll play around with
> Confluence a bit more.
> 
> But as mentioned before, perhaps I am making too much out of tracking this
> review.
> 
> Thanks,
> 
> Dan.
> 
> 
> On Fri, 27 Jan 2023 at 17:05, gil.portenseigne 
> wrote:
> 
>> I got to leave, but i generated in confluence a list of check, is that
>> good enough ?
>> 
>> Gil
>> On 27/01/23 05:41, gil.portenseigne wrote:
>>> Hello, indeed, that will generate much spam, i did some before reading
>>> your answer.
>>> 
>>> I'll have a look for conluence.
>>> 
>>> Gil
>>> 
>>> 
>>> On 27/01/23 04:14, Daniel Watford wrote:
 Hi Gill and Jacques,
 
 I don't think we should add comments to the PR to track the files that
>> we
 have reviewed as I think each comment will appear separately in the
>> PR's
 conversation view.
 
 However, with such a large PR where we hope to get several reviewers
 involved I think we do need a mechanism to track reviewed files.
 
 I created a page here - Codenarc integration review tracker - OFBiz
>> Project
 Open Wiki - Apache Software Foundation
 <
>> https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker
>>> 
 -
 suggesting an approach.
 
 If the approach is acceptable then all reviewers should be able to
>> update
 the page as we go.
 
 I'm stuck with finding a nice way to generate a table listing all the
 changed files and the review status of each file. I have included the
 commands to produce the list of files and shown some examples of how
>> to add
 a header, but my attempts to turn that into something useful on a
 confluence page have not been fruitful.
 
 So two questions.
 - Is it worth coming up with a page/table to track this PR or am I just
 creating unnecessary admin work when we could use comments in the PR?
 - Can anyone create a table in Confluence that we could use to track
>> the
 review effort?
 
 Thanks,
 
 Dan.
 
 
 On Fri, 27 Jan 2023 at 15:27, gil.portenseigne <
>> gil.portensei...@nereide.fr>
 wrote:
 
> Oops, i did a fixup commit with push force that remove all comments
>> in
> the pull request... Will not do that again.
> 
> I fixed the detected typo.
> 
> gil
> On 27/01/23 02:56, Jacques Le Roux wrote:
>> …
>> the pull
>> …
>> checkbox if a
>> …
>> request,
>> …
>> to the
> same conclusion.
>> …
>> Could
> be easy if it's the same unique words in every file.
>> …
>> concern
> one
>> …
>> but it
>> …
>> file, to
> let
>> …
>> "Review
> changes" button allows you to comment, approve or request changes on
>> this
> file.
>> …
>> can
> mark an
>> …
>> reviewers
> can skip
>> …
> 
 
 
 --
 Daniel Watford
>> 
>> 
>> 
> 
> -- 
> Daniel Watford

Re: Codenarc integration process

[Gil Portenseigne]

Haha, i understand, I will continue reviewing and testing while others can 
review also,

Thanks Jacques

21 janv. 2023 10:43:08 Jacques Le Roux :

> Thanks Gil,
> 
> OK, seems good to me to avoid gstring indeed.
> 
> I had a glance, I was too optimistic. I'll not review the 455(!) files and 
> will rather call our CTR mode as I'm much confident in your (big) work :)
> 
> +1 from my side
> 
> Jacques
> 
> 
> Le 21/01/2023 à 09:57, Gil Portenseigne a écrit :
>> Yes, it is considered best practice to avoid gstring usage when not needed.
>> 
>> Like for others, we can decide to not apply this rule.
>> 
>> The detailed rule from codenarc documentation :
>> 
>> 
>> *UnnecessaryGString** Rule*
>> 
>> /Since //CodeNarc// 0.13/
>> 
>> String objects should be created with single quotes, and GString objects 
>> created with double quotes. Creating normal String objects with double 
>> quotes is confusing to readers.
>> 
>> Gil
>> 
>> 21 janv. 2023 09:41:39 Jacques Le Roux :
>> 
>>> Hi Gil,
>>> 
>>> So we need to use single quotes instead of double quotes now in Groovy?
>>> 
>>> Thanks
>>> 
>>> Jacques
>>> 
>>> Le 20/01/2023 à 17:01, Jacques Le Roux a écrit :
>>>> Thank you very much Gil,
>>>> 
>>>> +1 for a big squash... after some reviews...
>>>> 
>>>> Jacques
>>>> 
>>>> Le 20/01/2023 à 15:53, gil.portenseigne a écrit :
>>>>> Hello Devs,
>>>>> 
>>>>> That is with pleasure, that I managed to integrate into OFBiz framework
>>>>> (no plugins yet) Codenarc, and that the build is successful under java
>>>>> 17.
>>>>> 
>>>>> https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
>>>>> 
>>>>> I tried to isolate rule fixes in separated commits, there are a lot (133
>>>>> commits), with some redundancy. But rebasing is not easy since files are
>>>>> modified by several rule fixing.
>>>>> 
>>>>> Integration and unit test are ok. I did some manual testing when I got
>>>>> some doubt, but it could be nice to have some more eyes on the subject.
>>>>> 
>>>>> After reviewing process, and if everything is fine, should we commit
>>>>> that as a big squash ?
>>>>> 
>>>>> WDYT
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Gil

Re: Codenarc integration process

[Gil Portenseigne]

Yes, it is considered best practice to avoid gstring usage when not needed.

Like for others, we can decide to not apply this rule.

The detailed rule from codenarc documentation :


*UnnecessaryGString** Rule*

/Since //CodeNarc// 0.13/

String objects should be created with single quotes, and GString objects 
created with double quotes. Creating normal String objects with double quotes 
is confusing to readers.

Gil

21 janv. 2023 09:41:39 Jacques Le Roux :

> Hi Gil,
> 
> So we need to use single quotes instead of double quotes now in Groovy?
> 
> Thanks
> 
> Jacques
> 
> Le 20/01/2023 à 17:01, Jacques Le Roux a écrit :
>> Thank you very much Gil,
>> 
>> +1 for a big squash... after some reviews...
>> 
>> Jacques
>> 
>> Le 20/01/2023 à 15:53, gil.portenseigne a écrit :
>>> Hello Devs,
>>> 
>>> That is with pleasure, that I managed to integrate into OFBiz framework
>>> (no plugins yet) Codenarc, and that the build is successful under java
>>> 17.
>>> 
>>> https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
>>> 
>>> I tried to isolate rule fixes in separated commits, there are a lot (133
>>> commits), with some redundancy. But rebasing is not easy since files are
>>> modified by several rule fixing.
>>> 
>>> Integration and unit test are ok. I did some manual testing when I got
>>> some doubt, but it could be nice to have some more eyes on the subject.
>>> 
>>> After reviewing process, and if everything is fine, should we commit
>>> that as a big squash ?
>>> 
>>> WDYT
>>> 
>>> Regards,
>>> 
>>> Gil

[jira] [Closed] (OFBIZ-12732) Error in BlackList to DenyList migration service

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12732.

Resolution: Fixed

> Error in BlackList to DenyList migration service
> 
>
> Key: OFBIZ-12732
> URL: https://issues.apache.org/jira/browse/OFBIZ-12732
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: 22.01.01
>
>
> While reviewing groovy files for codenarc integration i stumbled upon 
> OrderBlacklistServices.groovy that present some implementation issue.
>  
> This Jira is about fixing the implementation of this service.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12732) Error in BlackList to DenyList migration service

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12732:
-
Fix Version/s: 22.01.01

> Error in BlackList to DenyList migration service
> 
>
> Key: OFBIZ-12732
> URL: https://issues.apache.org/jira/browse/OFBIZ-12732
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: 22.01.01
>
>
> While reviewing groovy files for codenarc integration i stumbled upon 
> OrderBlacklistServices.groovy that present some implementation issue.
>  
> This Jira is about fixing the implementation of this service.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-12732) Error in BlackList to DenyList migration service

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12732:
-
Affects Version/s: (was: 18.12.06)

> Error in BlackList to DenyList migration service
> 
>
> Key: OFBIZ-12732
> URL: https://issues.apache.org/jira/browse/OFBIZ-12732
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
>
> While reviewing groovy files for codenarc integration i stumbled upon 
> OrderBlacklistServices.groovy that present some implementation issue.
>  
> This Jira is about fixing the implementation of this service.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (OFBIZ-12732) Error in BlackList to DenyList migration service

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12732:


 Summary: Error in BlackList to DenyList migration service
 Key: OFBIZ-12732
 URL: https://issues.apache.org/jira/browse/OFBIZ-12732
 Project: OFBiz
  Issue Type: Bug
Affects Versions: 18.12.06, Upcoming Branch
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


While reviewing groovy files for codenarc integration i stumbled upon 
OrderBlacklistServices.groovy that present some implementation issue.

 

This Jira is about fixing the implementation of this service.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-12725) Cannot expand tree of accounts in Navigate Accounts screen with Helveticus theme

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-12725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652186#comment-17652186
 ] 

Gil Portenseigne commented on OFBIZ-12725:
--

Hello [~jleroux] , [~marine] is the person you meant to contact I guess, I 
transfer the info to let her know :)

Thanks

> Cannot expand tree of accounts in Navigate Accounts screen with Helveticus 
> theme
> 
>
> Key: OFBIZ-12725
> URL: https://issues.apache.org/jira/browse/OFBIZ-12725
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: accounting, themes/helveticus
>Affects Versions: 22.01.01
>Reporter: Daniel Watford
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: 22.01.01
>
>
> Viewing [OFBiz: Accounting Manager: Navigate Accounts 
> (apache.org)|https://demo-next.ofbiz.apache.org/accounting/control/GlAccountNavigate?trail=null],
>  it is not possible to expand the chart-of-accounts tree when the Helveticus 
> visual theme is used.
> The Helveticus theme is the default theme for new deployments.
> A workaround is to switch to a non-Helveticus theme.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (OFBIZ-11167) Use Codenarc to test Groovy code

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-11167:
-
Description: 
Thread of community discussion about the rules to implement : 
https://www.mail-archive.com/search?l=dev%40ofbiz.apache.org=subject:%22Codenarc+integration%2C+rules+to+use.%22=newest=1

 

Now that we use Groovy more and more, I think we should really have a look a 
Codenarc
[https://docs.gradle.org/current/userguide/codenarc_plugin.html]

We already discussed it at [https://markmail.org/message/uigcpnxqgizhd2oi] and 
[https://markmail.org/message/rp6njoiohkkiodbe]

We know it's a crucial task but not an easy but rather a long term one

Here are some interesting links (before I delete my FF tabs group about it)
[http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html]
[http://codenarc.sourceforge.net/codenarc-creating-ruleset.html]
[https://github.com/gradle/gradle/tree/master/config]
[https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s]
[https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html]

  was:
Now that we use Groovy more and more, I think we should really have a look a 
Codenarc
https://docs.gradle.org/current/userguide/codenarc_plugin.html

We already discussed it at https://markmail.org/message/uigcpnxqgizhd2oi and 
https://markmail.org/message/rp6njoiohkkiodbe

We know it's a crucial task but not an easy but rather a long term one

Here are some interesting links (before I delete my FF tabs group about it)
http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html
http://codenarc.sourceforge.net/codenarc-creating-ruleset.html
https://github.com/gradle/gradle/tree/master/config
https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s
https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html


> Use Codenarc to test Groovy code
> 
>
> Key: OFBIZ-11167
> URL: https://issues.apache.org/jira/browse/OFBIZ-11167
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-11167.patch, main.html, test.html
>
>
> Thread of community discussion about the rules to implement : 
> https://www.mail-archive.com/search?l=dev%40ofbiz.apache.org=subject:%22Codenarc+integration%2C+rules+to+use.%22=newest=1
>  
> Now that we use Groovy more and more, I think we should really have a look a 
> Codenarc
> [https://docs.gradle.org/current/userguide/codenarc_plugin.html]
> We already discussed it at [https://markmail.org/message/uigcpnxqgizhd2oi] 
> and [https://markmail.org/message/rp6njoiohkkiodbe]
> We know it's a crucial task but not an easy but rather a long term one
> Here are some interesting links (before I delete my FF tabs group about it)
> [http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html]
> [http://codenarc.sourceforge.net/codenarc-creating-ruleset.html]
> [https://github.com/gradle/gradle/tree/master/config]
> [https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s]
> [https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OFBIZ-11167) Use Codenarc to test Groovy code

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648644#comment-17648644
 ] 

Gil Portenseigne commented on OFBIZ-11167:
--

Work still ongoing, i propose to remove rule TrailingComma : Check whether list 
and map literals contain optional trailing comma.

> Use Codenarc to test Groovy code
> 
>
> Key: OFBIZ-11167
> URL: https://issues.apache.org/jira/browse/OFBIZ-11167
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-11167.patch, main.html, test.html
>
>
> Now that we use Groovy more and more, I think we should really have a look a 
> Codenarc
> https://docs.gradle.org/current/userguide/codenarc_plugin.html
> We already discussed it at https://markmail.org/message/uigcpnxqgizhd2oi and 
> https://markmail.org/message/rp6njoiohkkiodbe
> We know it's a crucial task but not an easy but rather a long term one
> Here are some interesting links (before I delete my FF tabs group about it)
> http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html
> http://codenarc.sourceforge.net/codenarc-creating-ruleset.html
> https://github.com/gradle/gradle/tree/master/config
> https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s
> https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Welcome to Leila Mekika as new committer

[Gil Portenseigne]

Congratulations Leila ! Bravo !

Gil

On 04/10/2022 09:30, MLeila wrote:

Hello all,

Thanks for your welcome!
I am glad to join the team and be able to contribute more actively on 
the project


Regards,
Leila

Le 04/10/2022 à 07:38, Devanshu Vyas a écrit :

Many congratulations and welcome aboard Leila!!

Thanks & Regards,
Devanshu Vyas.


On Mon, Oct 3, 2022 at 6:27 PM Nicolas Malin 
wrote:


The OFBiz PMC has invited Leila Mekika as new
committer and we are glad to announce that she have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: Ofbiz using itext-2.1.7

[Gil Portenseigne]

Hello Rishin,

This Itext version was the last version that could be included in OFBiz
regarding the Licence (MPL).

Nothing to worry about this.

Regards,

Gil

Details : https://www.apache.org/legal/resolved

On Fri, Aug 12, 2022 at 08:15:37AM +0200, Rishi Agr wrote:
> Hi, There is a usage of itext-2.1.7 (com.lowagie) library in ofbiz. And I
> am not sure if this comes under open source or some other license. Is it
> fine to use apache in commercial applications as it includes itext library?
> Thank you.


signature.asc
Description: PGP signature

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Hello Jacques, 

Thanks for your feedback, I'll go with that.

Gil
On Mon, Jul 25, 2022 at 10:08:20AM +0200, Jacques Le Roux wrote:
> Hi Gil,
> 
> Here are my preferences inline...
> 
> Le 20/07/2022 à 23:49, Gil Portenseigne a écrit :
> > Thanks All for the feedback.
> > 
> > I continue in my spare time and did analyse some rule that I propose to 
> > disable.
> > Here are my thought :
> > 
> > * DuplicateStringLiteral :  Not Adapted to OFBiz : String Literal are 
> > massively entityName. No need to make them constants.
> 
> +1
> 
> > * LineLength : Can be configured : default 120, with 140 configured there 
> > are 654 fix needed, 445 fixes to 150 length configuration (same as Java 
> > checkstyle). IMO I prefer default config, but we could go with the same as 
> > checkstyle config ?
> 150
> > * UnnecessaryGetter : Lot of java OFBiz code use getXXX. Applying this 
> > rule, will lead massive java changes. I prefer to ignore.
> +1
> >   * NoDef : We need to agree to not use def in variable declaration or 
> > method return type (implies lots of fix). I think that is better to have 
> > type defined.
> +1
> > * MethodReturnTypeRequired : same as above
> +1
> > * UnnecessaryReturnKeyword : Not sure that is is wanted, in our dev team it 
> > can be disturbing, *WDYT* ?
> Better to have return, clearer
> > * UnnecessaryObjectReferences : with method usage to reduce code. 
> > Context.with { toto = « toto »}, I was unaware of this, i'd like to keep it 
> > if possible.
> +1
> > * CompileStatic : I propose to ignore this rule, not needed IMO
> +1
> >   IfStatementBraces : Do we allow one lined if without braces ? I prefer 
> > not, but that seems convenient some times, This rule applies also on 
> > multiline, and for me we should keep it. Since it is not configurable for 
> > oneline, i am into keeping it.
> +1
> > * DuplicateNumberLiteral : Same as String Literal
> +1
> > * UnnecessarySetter : Same as UnnecessaryGetter
> 
> +1
> 
> Thanks
> 
> Jacques
> 
> > 
> > Thanks,
> > 
> > Gil
> > 
> > On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> > > Hello Devs,
> > > 
> > > I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
> > > 
> > > For those who are not aware, Codenarc is an analysis tools for Groovy
> > > for defects, bad practices, inconsistencies, style issues and more.
> > > 
> > > For this purpose we need to agree about the ruleset to put in place.
> > > 
> > > I took as a basis the ruleset :
> > > https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
> > > 
> > > And started to fix some in 
> > > https://github.com/apache/ofbiz-framework/pull/517
> > > 
> > > Before doing the complete work, a first rule made me wonder if that is a
> > > choice that we will be doing as a community :
> > > 
> > > IfStatementBraces - Use braces for if statements, even for a single 
> > > statement.
> > > 
> > > There are 234 occurrences in the project, and I guess that some opinions
> > > might diverge on this subject.
> > > 
> > > Moreover, some rules needs lots of fixes in the project (those with more
> > > than 200 occurrences) :
> > > 
> > > ++-+
> > > | Number of  | Rule name and details  
> > >  |
> > > | occurrence |
> > >  |
> > > ++=+
> > > | 9883   | UnnecessaryGString  - String objects should be created 
> > > with single  |
> > > ||  quotes, and GString  objects created with double quotes. 
> > > Creating  |
> > > ||  normal String objects with  double quotes is confusing to 
> > > readers. |
> > > ++-+
> > > | 4569   | DuplicateStringLiteral  - Code containing duplicate String 
> > > literals |
> > > ||  can usually be improved by  declaring the String as a 
> > > constant |
> > > || field. The ignoreStrings property ()  can optionally 
> > > specify a  |
> > > || comma-separated list of Strings to ignore. 
> > >  |
> 

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Thanks All for the feedback.

I continue in my spare time and did analyse some rule that I propose to disable.
Here are my thought : 

* DuplicateStringLiteral :  Not Adapted to OFBiz : String Literal are 
massively entityName. No need to make them constants.
* LineLength : Can be configured : default 120, with 140 configured there are 
654 fix needed, 445 fixes to 150 length configuration (same as Java 
checkstyle). IMO I prefer default config, but we could go with the same as 
checkstyle config ?
* UnnecessaryGetter : Lot of java OFBiz code use getXXX. Applying this rule, 
will lead massive java changes. I prefer to ignore.
 * NoDef : We need to agree to not use def in variable declaration or method 
return type (implies lots of fix). I think that is better to have type defined.
* MethodReturnTypeRequired : same as above
* UnnecessaryReturnKeyword : Not sure that is is wanted, in our dev team it can 
be disturbing, *WDYT* ? 
* UnnecessaryObjectReferences : with method usage to reduce code. Context.with 
{ toto = « toto »}, I was unaware of this, i'd like to keep it if possible.
* CompileStatic : I propose to ignore this rule, not needed IMO
 IfStatementBraces : Do we allow one lined if without braces ? I prefer not, 
but that seems convenient some times, This rule applies also on multiline, and 
for me we should keep it. Since it is not configurable for oneline, i am into 
keeping it.
* DuplicateNumberLiteral : Same as String Literal
* UnnecessarySetter : Same as UnnecessaryGetter

Thanks,

Gil

On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> Hello Devs,
> 
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
> 
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
> 
> For this purpose we need to agree about the ruleset to put in place.
> 
> I took as a basis the ruleset : 
> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
> 
> And started to fix some in https://github.com/apache/ofbiz-framework/pull/517
> 
> Before doing the complete work, a first rule made me wonder if that is a
> choice that we will be doing as a community : 
> 
> IfStatementBraces - Use braces for if statements, even for a single statement.
> 
> There are 234 occurrences in the project, and I guess that some opinions
> might diverge on this subject.
> 
> Moreover, some rules needs lots of fixes in the project (those with more
> than 200 occurrences) :
> 
> ++-+
> | Number of  | Rule name and details  
>  |
> | occurrence |
>  |
> ++=+
> | 9883   | UnnecessaryGString  - String objects should be created with 
> single  |
> ||  quotes, and GString  objects created with double quotes. 
> Creating  |
> ||  normal String objects with  double quotes is confusing to 
> readers. |
> ++-+
> | 4569   | DuplicateStringLiteral  - Code containing duplicate String 
> literals |
> ||  can usually be improved by  declaring the String as a 
> constant |
> || field. The ignoreStrings property ()  can optionally specify a 
>  |
> || comma-separated list of Strings to ignore. 
>  |
> ++-+
> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting of 
>  |
> || whitespace around colons for  literal Map entries. 
>  |
> || The characterBeforeColonRegex and  characterAfterColonRegex
>  |
> || properties specify a regular expression that  must match the   
>  |
> || character before/after the colon.  
>  |
> ++-+
> | 1448   | LineLength  - Checks the maximum length for each line of   
>  |
> || source code. It checks for  number of characters, so lines 
>  |
> ||  that include tabs may appear longer than  the allowed number  
>  |
> ||  when viewing the file. The maximum line length can  be
>  |
> || configured by setting the length property, which defaults to 
> 120.   |
> ++-+
> | 885| UnnecessaryGetter  - Checks f

Re: Codenarc integration, rules to use.

[gil . portenseigne]

Hello Michael,

Sure, you can see in the pull request I started to separate the commit, a 
commit for one rule fix.

The last one is a big one :)

https://github.com/apache/ofbiz-framework/pull/517/commits/384894dfafce5e7261e2564b40261650deda7a22

Regards,

Gil


Le Dimanche, Juillet 10, 2022 16:02 CEST, Michael Brohl 
 a écrit:
 Hi Gil,

I was on vacation so a bit late: I fully agree to apply these rules.

We should, however, encourage contributors to apply those changes in
separate commits which ONLY contain those changes and not mix it up with
other changes to make review work easier.

Thanks for the initiative,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 04.07.22 um 17:24 schrieb Gil Portenseigne:
> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
>
> For this purpose we need to agree about the ruleset to put in place.
>
> I took as a basis the ruleset :
> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>
> And started to fix some in https://github.com/apache/ofbiz-framework/pull/517
>
> Before doing the complete work, a first rule made me wonder if that is a
> choice that we will be doing as a community :
>
> IfStatementBraces - Use braces for if statements, even for a single statement.
>
> There are 234 occurrences in the project, and I guess that some opinions
> might diverge on this subject.
>
> Moreover, some rules needs lots of fixes in the project (those with more
> than 200 occurrences) :
>
> ++-+
> | Number of | Rule name and details |
> | occurrence | |
> ++=+
> | 9883 | UnnecessaryGString - String objects should be created with single |
> | | quotes, and GString objects created with double quotes. Creating |
> | | normal String objects with double quotes is confusing to readers. |
> ++-+
> | 4569 | DuplicateStringLiteral - Code containing duplicate String literals |
> | | can usually be improved by declaring the String as a constant |
> | | field. The ignoreStrings property () can optionally specify a |
> | | comma-separated list of Strings to ignore. |
> ++-+
> | 4209 | SpaceAroundMapEntryColon - Check for configured formatting of |
> | | whitespace around colons for literal Map entries. |
> | | The characterBeforeColonRegex and characterAfterColonRegex |
> | | properties specify a regular expression that must match the |
> | | character before/after the colon. |
> ++-+
> | 1448 | LineLength - Checks the maximum length for each line of |
> | | source code. It checks for number of characters, so lines |
> | | that include tabs may appear longer than the allowed number |
> | | when viewing the file. The maximum line length can be |
> | | configured by setting the length property, which defaults to 120. |
> ++-+
> | 885 | UnnecessaryGetter - Checks for explicit calls to getter/accessor |
> | | methods which can, for the most part, be replaced by property |
> | | access. A getter is defined as a method call that matches |
> | | get[A-Z] but not getClass() or get[A-Z][A-Z] such as getURL(). |
> | | Getters do not take method arguments. The ignoreMethodNames |
> | | property (null) can specify method names that should be ignored |
> | | , optionally containing wildcard characters ('*' or '?'). |
> ++-+
> | 601 | NoDef - def should not be used. You should replace it with |
> | | concrete type. |
> ++-+
> | 485 | MethodReturnTypeRequired - Checks that method return types |
> | | are not dynamic, that is they are explicitly stated and |
> | | different than def. |
> ++-+
> | 484 | Indentation - Check indentation for class and method |
> | | declarations, and initial statements. |
> ++-+
> | 482 | UnnecessaryReturnKeyword - In Groovy, the return keyword |
> | | is often optional. If a statement is the last line in a |
> | | method or closure then you do not need to have the return keyword. |
> +--

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Forgot the ref https://github.com/CodeNarc/CodeNarc/issues/331

Le 12 juillet 2022 21:11:13 GMT+02:00, Gil Portenseigne 
 a écrit :
>Hello, 
>
>I agree with you, i find out here [1] that it is customisable.
>
>So we can agree upon this variation of the rule !
>
>I have not tested yet, will see in the near future 
>
>Thanks
>
>Gil
>
>Le 11 juillet 2022 17:57:45 GMT+02:00, Scott Gray  a écrit :
>>+1 in general from me although some of those rules might be challenging to
>>resolve.  For example DuplicateStringLiteral could be referring to an
>>entity name being used in delegator queries more than once, I don't think
>>we'd prefer to see that extracted to a constant.
>>
>>SpaceAroundMapEntryColon I'm not so sure about, my preference for
>>legibility has always been [someKey: someValue].  I find
>>[someKey:someValue] a bit too condensed and harder to differentiate key
>>from value.
>>
>>Regards
>>Scott
>>
>>On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne 
>>wrote:
>>
>>> Hello Devs,
>>>
>>> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>>>
>>> For those who are not aware, Codenarc is an analysis tools for Groovy
>>> for defects, bad practices, inconsistencies, style issues and more.
>>>
>>> For this purpose we need to agree about the ruleset to put in place.
>>>
>>> I took as a basis the ruleset :
>>> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>>>
>>> And started to fix some in
>>> https://github.com/apache/ofbiz-framework/pull/517
>>>
>>> Before doing the complete work, a first rule made me wonder if that is a
>>> choice that we will be doing as a community :
>>>
>>> IfStatementBraces - Use braces for if statements, even for a single
>>> statement.
>>>
>>> There are 234 occurrences in the project, and I guess that some opinions
>>> might diverge on this subject.
>>>
>>> Moreover, some rules needs lots of fixes in the project (those with more
>>> than 200 occurrences) :
>>>
>>>
>>> ++-+
>>> | Number of  | Rule name and details
>>>  |
>>> | occurrence |
>>>  |
>>>
>>> ++=+
>>> | 9883   | UnnecessaryGString  - String objects should be created with
>>> single  |
>>> ||  quotes, and GString  objects created with double quotes.
>>> Creating  |
>>> ||  normal String objects with  double quotes is confusing to
>>> readers. |
>>>
>>> ++-+
>>> | 4569   | DuplicateStringLiteral  - Code containing duplicate String
>>> literals |
>>> ||  can usually be improved by  declaring the String as a
>>> constant |
>>> || field. The ignoreStrings property ()  can optionally
>>> specify a  |
>>> || comma-separated list of Strings to ignore.
>>> |
>>>
>>> ++-+
>>> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting
>>> of  |
>>> || whitespace around colons for  literal Map entries.
>>> |
>>> || The characterBeforeColonRegex and
>>> characterAfterColonRegex |
>>> || properties specify a regular expression that  must match
>>> the|
>>> || character before/after the colon.
>>>  |
>>>
>>> ++-+
>>> | 1448   | LineLength  - Checks the maximum length for each line of
>>> |
>>> || source code. It checks for  number of characters, so lines
>>> |
>>> ||  that include tabs may appear longer than  the allowed
>>> number   |
>>> ||  when viewing the file. The maximum line length can  be
>>>  |
>>> || configured by setting the length property, which defaults
>>> to 120.   |
>>>
>>> ++-+
>>> | 885| Unnecessar

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Hello, 

I agree with you, i find out here [1] that it is customisable.

So we can agree upon this variation of the rule !

I have not tested yet, will see in the near future 

Thanks

Gil

Le 11 juillet 2022 17:57:45 GMT+02:00, Scott Gray  a écrit :
>+1 in general from me although some of those rules might be challenging to
>resolve.  For example DuplicateStringLiteral could be referring to an
>entity name being used in delegator queries more than once, I don't think
>we'd prefer to see that extracted to a constant.
>
>SpaceAroundMapEntryColon I'm not so sure about, my preference for
>legibility has always been [someKey: someValue].  I find
>[someKey:someValue] a bit too condensed and harder to differentiate key
>from value.
>
>Regards
>Scott
>
>On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne 
>wrote:
>
>> Hello Devs,
>>
>> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>>
>> For those who are not aware, Codenarc is an analysis tools for Groovy
>> for defects, bad practices, inconsistencies, style issues and more.
>>
>> For this purpose we need to agree about the ruleset to put in place.
>>
>> I took as a basis the ruleset :
>> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>>
>> And started to fix some in
>> https://github.com/apache/ofbiz-framework/pull/517
>>
>> Before doing the complete work, a first rule made me wonder if that is a
>> choice that we will be doing as a community :
>>
>> IfStatementBraces - Use braces for if statements, even for a single
>> statement.
>>
>> There are 234 occurrences in the project, and I guess that some opinions
>> might diverge on this subject.
>>
>> Moreover, some rules needs lots of fixes in the project (those with more
>> than 200 occurrences) :
>>
>>
>> ++-+
>> | Number of  | Rule name and details
>>  |
>> | occurrence |
>>  |
>>
>> ++=+
>> | 9883   | UnnecessaryGString  - String objects should be created with
>> single  |
>> ||  quotes, and GString  objects created with double quotes.
>> Creating  |
>> ||  normal String objects with  double quotes is confusing to
>> readers. |
>>
>> ++-+
>> | 4569   | DuplicateStringLiteral  - Code containing duplicate String
>> literals |
>> ||  can usually be improved by  declaring the String as a
>> constant |
>> || field. The ignoreStrings property ()  can optionally
>> specify a  |
>> || comma-separated list of Strings to ignore.
>> |
>>
>> ++-+
>> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting
>> of  |
>> || whitespace around colons for  literal Map entries.
>> |
>> || The characterBeforeColonRegex and
>> characterAfterColonRegex |
>> || properties specify a regular expression that  must match
>> the|
>> || character before/after the colon.
>>  |
>>
>> ++-+
>> | 1448   | LineLength  - Checks the maximum length for each line of
>> |
>> || source code. It checks for  number of characters, so lines
>> |
>> ||  that include tabs may appear longer than  the allowed
>> number   |
>> ||  when viewing the file. The maximum line length can  be
>>  |
>> || configured by setting the length property, which defaults
>> to 120.   |
>>
>> ++-+
>> | 885| UnnecessaryGetter  - Checks for explicit calls to
>> getter/accessor   |
>> ||  methods which can, for  the most part, be replaced by
>> property |
>> ||  access. A getter is defined as a  method call that
>> matches |
>> || get[A-Z] but not getClass() or get[A-Z][A-Z]  such as
>> getURL(). |
>> ||  Getters do not take method arguments. The
>> ignoreMethodNames   |
>> || property (null) can specify method names that should  be
>> i

Codenarc integration, rules to use.

[Gil Portenseigne]

Hello Devs,

I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).

For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style issues and more.

For this purpose we need to agree about the ruleset to put in place.

I took as a basis the ruleset : 
https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt

And started to fix some in https://github.com/apache/ofbiz-framework/pull/517

Before doing the complete work, a first rule made me wonder if that is a
choice that we will be doing as a community : 

IfStatementBraces - Use braces for if statements, even for a single statement.

There are 234 occurrences in the project, and I guess that some opinions
might diverge on this subject.

Moreover, some rules needs lots of fixes in the project (those with more
than 200 occurrences) :

++-+
| Number of  | Rule name and details
   |
| occurrence |  
   |
++=+
| 9883   | UnnecessaryGString  - String objects should be created with 
single  |
||  quotes, and GString  objects created with double quotes. 
Creating  |
||  normal String objects with  double quotes is confusing to 
readers. |
++-+
| 4569   | DuplicateStringLiteral  - Code containing duplicate String 
literals |
||  can usually be improved by  declaring the String as a constant  
   |
|| field. The ignoreStrings property ()  can optionally specify a   
   |
|| comma-separated list of Strings to ignore.   
   |
++-+
| 4209   | SpaceAroundMapEntryColon  - Check for configured formatting of   
   |
|| whitespace around colons for  literal Map entries.   
   |
|| The characterBeforeColonRegex and  characterAfterColonRegex  
   |
|| properties specify a regular expression that  must match the 
   |
|| character before/after the colon.
   |
++-+
| 1448   | LineLength  - Checks the maximum length for each line of 
   |
|| source code. It checks for  number of characters, so lines   
   |
||  that include tabs may appear longer than  the allowed number
   |
||  when viewing the file. The maximum line length can  be  
   |
|| configured by setting the length property, which defaults to 
120.   |
++-+
| 885| UnnecessaryGetter  - Checks for explicit calls to 
getter/accessor   |
||  methods which can, for  the most part, be replaced by property  
   |
||  access. A getter is defined as a  method call that matches  
   |
|| get[A-Z] but not getClass() or get[A-Z][A-Z]  such as getURL().  
   |
||  Getters do not take method arguments. The  ignoreMethodNames
   |
|| property (null) can specify method names that should  be ignored 
   |
|| , optionally containing wildcard characters ('*' or '?').
   |
++-+
| 601| NoDef - def should not be used. You should replace it with   
   |
|| concrete type.   
   |
++-+
| 485| MethodReturnTypeRequired  - Checks that method return types  
   |
||  are not dynamic, that is they are  explicitly stated and
   |
||  different than def. 
   |
++-+
| 484| Indentation - Check indentation for class and method 
   |
|| declarations, and initial statements.
   |
++-+
| 482| UnnecessaryReturnKeyword  - In Groovy, the return keyword
   |
||  is often optional. If a statement is  the last line in a
   |
|| method or closure then you do not need to have the return 
keyword.  |
++-+
| 407| UnnecessaryObjectReferences  - Violations are triggered when 
   |
| 

[jira] [Commented] (OFBIZ-11167) Use Codenarc to test Groovy code

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561935#comment-17561935
 ] 

Gil Portenseigne commented on OFBIZ-11167:
--

I wrote a little script to extract the rules in order of occurrence. I will 
launch an email to the dev list to discuss about the rules to be respected, and 
the implied changes.

There are the results :
||Number of occurence||Rule name and details||
|9883|UnnecessaryGString - String objects should be created with single quotes, 
and GString objects created with double quotes. Creating normal String objects 
with double quotes is confusing to readers.|
|4569|DuplicateStringLiteral - Code containing duplicate String literals can 
usually be improved by declaring the String as a constant field. The 
ignoreStrings property () can optionally specify a comma-separated list of 
Strings to ignore.|
|4209|SpaceAroundMapEntryColon - Check for configured formatting of whitespace 
around colons for literal Map entries. The characterBeforeColonRegex and 
characterAfterColonRegex properties specify a regular expression that must 
match the character before/after the colon.|
|1448|LineLength - Checks the maximum length for each line of source code. It 
checks for number of characters, so lines that include tabs may appear longer 
than the allowed number when viewing the file. The maximum line length can be 
configured by setting the length property, which defaults to 120.|
|885|UnnecessaryGetter - Checks for explicit calls to getter/accessor methods 
which can, for the most part, be replaced by property access. A getter is 
defined as a method call that matches get[A-Z] but not getClass() or 
get[A-Z][A-Z] such as getURL(). Getters do not take method arguments. The 
ignoreMethodNames property (null) can specify method names that should be 
ignored, optionally containing wildcard characters ('*' or '?').|
|601|NoDef - def should not be used. You should replace it with concrete type.|
|485|MethodReturnTypeRequired - Checks that method return types are not 
dynamic, that is they are explicitly stated and different than def.|
|484|Indentation - Check indentation for class and method declarations, and 
initial statements.|
|482|UnnecessaryReturnKeyword - In Groovy, the return keyword is often 
optional. If a statement is the last line in a method or closure then you do 
not need to have the return keyword.|
|407|UnnecessaryObjectReferences - Violations are triggered when an excessive 
set of consecutive statements all reference the same variable. This can be made 
more readable by using a with or identity block.|
|345|CompileStatic - Check that classes are explicitely annotated with either 
@GrailsCompileStatic, @CompileStatic or @CompileDynamic|
|320|ExplicitCallToEqualsMethod - This rule detects when the equals(Object) 
method is called directly in code instead of using the == or != operator. A 
groovier way to express this: a.equals(b) is this: a == b and a groovier way to 
express : !a.equals(b) is : a != b|
|235|IfStatementBraces - Use braces for if statements, even for a single 
statement.|
|235|SpaceAroundOperator - Check that there is at least one space (blank) or 
whitespace around each binary operator.|
|211|NestedBlockDepth - Checks for blocks or closures nested more than 
maxNestedBlockDepth (5) levels deep.|
|201|TrailingWhitespace - Checks that no lines of source code end with 
whitespace characters.|
|190|DuplicateNumberLiteral - Code containing number String literals can 
usually be improved by declaring the number as a constant field. The 
ignoreNumbers property (0,1) can optionally specify a comma-separated list of 
numbers to ignore.|
|190|NoWildcardImports - Wildcard imports, static or otherwise, should not be 
used.|
|173|TrailingComma - Check whether list and map literals contain optional 
trailing comma.|
|167|InvertedCondition - An inverted condition is one where a constant 
expression is used on the left hand side of the equals comparision. Such 
conditions can be confusing especially when used in assertions where the 
expected value is by convention placed on the right hand side of the 
comparision.|
|167|JavadocEmptyReturnTag - Checks for empty @return tags within javadoc.|
|164|UnnecessarySetter - Checks for explicit calls to setter methods which can, 
for the most part, be replaced by assignment to property. A setter is defined 
as a method call that matches set[A-Z] but not set[A-Z][A-Z] such as setURL(). 
Setters take one method argument.|
|146|CouldBeElvis - Catch an if block that could be written as an elvis 
expression.|
|142|UnusedImport - Imports for a class that is never referenced within the 
source file is unnecessary.|
|141|AbcMetric - Checks the ABC size metric for methods/classes. A method (or 
"closure field") with an ABC score greater than the maxMethodAbcScore property 
(60) causes a violation. Likewise, a class that has a

[jira] [Commented] (OFBIZ-11167) Use Codenarc to test Groovy code

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561468#comment-17561468
 ] 

Gil Portenseigne commented on OFBIZ-11167:
--

Hello Folks, i dig up this subject and started to work on it actively, i will 
push my progress here [https://github.com/apache/ofbiz-framework/pull/517.]

The Idea is to document each rule, and make one commit by rule on the pull 
request to ease the review and decide if a rule is worth keeping etc.

 

> Use Codenarc to test Groovy code
> 
>
> Key: OFBIZ-11167
> URL: https://issues.apache.org/jira/browse/OFBIZ-11167
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-11167.patch, main.html, test.html
>
>
> Now that we use Groovy more and more, I think we should really have a look a 
> Codenarc
> https://docs.gradle.org/current/userguide/codenarc_plugin.html
> We already discussed it at https://markmail.org/message/uigcpnxqgizhd2oi and 
> https://markmail.org/message/rp6njoiohkkiodbe
> We know it's a crucial task but not an easy but rather a long term one
> Here are some interesting links (before I delete my FF tabs group about it)
> http://codenarc.sourceforge.net/codenarc-other-tools-frameworks.html
> http://codenarc.sourceforge.net/codenarc-creating-ruleset.html
> https://github.com/gradle/gradle/tree/master/config
> https://stackoverflow.com/questions/14358471/how-to-generate-codenarc-report-for-main-and-test-classes-using-different-rule-s
> https://mrhaki.blogspot.com/2011/01/gradle-goodness-use-groovy-ruleset-file.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (OFBIZ-10692) Groovy DSL runService Exception Management

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-10692.

Resolution: Fixed

Thanks [~mleila] , this is commited in trunk.

Regards,

Gil

> Groovy DSL runService Exception Management
> --
>
> Key: OFBIZ-10692
> URL: https://issues.apache.org/jira/browse/OFBIZ-10692
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Leila Mekika
>    Assignee: Gil Portenseigne
>Priority: Minor
>  Labels: patch
> Attachments: OFBIZ-10692-TEST.patch, OFBIZ-10692.patch, 
> Sélection_088.png, screenshot-1.png
>
>
> Like discussed in thread : 
> [https://lists.apache.org/thread.html/5a8e1caed0bcf29889c6b88ec1916947cf092d6f99d7dfe27cbef8c0@%3Cdev.ofbiz.apache.org%3E]
>   
>  This ticket try to improve the way that errors are rendered when using {{run 
> service}} groovy DSL method.
>  
>  To reproduce and test patch:
>  apply the attached patch [^OFBIZ-10692-TEST.patch] (it adds a control on 
> createUomConversionDated service) and try to create a conversion rate with a 
> fromDate greater than the thruDate here:
> https://localhost:8443/accounting/control/viewFXConversions?organizationPartyId=Company
>   
>  You should then see the following error:
>      The Following Errors Occurred: Error calling event: 
> org.apache.ofbiz.webapp.event.EventHandlerException: Service invocation error 
> (org.apache.ofbiz.service.ExecutionServiceException: Through date can't be 
> same or smaller than from date)
>   
>  With  [^OFBIZ-10692.patch]  update, the error must be displayed like:
>      The Following Errors Occurred: Through date can't be same or smaller 
> than from date
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (OFBIZ-10692) Groovy DSL runService Exception Management

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542922#comment-17542922
 ] 

Gil Portenseigne commented on OFBIZ-10692:
--

This ticket was in stand-by, we added some integration tests, i will provide a 
new patch soon.

> Groovy DSL runService Exception Management
> --
>
> Key: OFBIZ-10692
> URL: https://issues.apache.org/jira/browse/OFBIZ-10692
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Leila Mekika
>    Assignee: Gil Portenseigne
>Priority: Minor
>  Labels: patch
> Attachments: OFBIZ-10692-TEST.patch, OFBIZ-10692.patch, 
> Sélection_088.png, screenshot-1.png
>
>
> Like discussed in thread : 
> [https://lists.apache.org/thread.html/5a8e1caed0bcf29889c6b88ec1916947cf092d6f99d7dfe27cbef8c0@%3Cdev.ofbiz.apache.org%3E]
>   
>  This ticket try to improve the way that errors are rendered when using {{run 
> service}} groovy DSL method.
>  
>  To reproduce and test patch:
>  apply the attached patch [^OFBIZ-10692-TEST.patch] (it adds a control on 
> createUomConversionDated service) and try to create a conversion rate with a 
> fromDate greater than the thruDate here:
> https://localhost:8443/accounting/control/viewFXConversions?organizationPartyId=Company
>   
>  You should then see the following error:
>      The Following Errors Occurred: Error calling event: 
> org.apache.ofbiz.webapp.event.EventHandlerException: Service invocation error 
> (org.apache.ofbiz.service.ExecutionServiceException: Through date can't be 
> same or smaller than from date)
>   
>  With  [^OFBIZ-10692.patch]  update, the error must be displayed like:
>      The Following Errors Occurred: Through date can't be same or smaller 
> than from date
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: "New commiter first steps" wiki page proposal

[Gil Portenseigne]

Hello Giulio,

I just went through the page, it's nice and clear ! 

Thanks

Gil


Le samedi 14 mai 2022 à 16:32 +0200, Giulio Speri - MpStyle Srl a
écrit :
> Hello Devs,
> 
> I hope you are all doing well!
> I finally had some time to write a little guide regarding the steps
> to
> perform as a new committer in order to start working with online
> OFBiz
> repositories.
> I published the page in the section Community ->  Apache OFBiz
> Contribution
> and Development : OFBiz New Committer's first steps
> 
> 
> All the feedbacks and suggestions about it are happily appreciated.
> :)
> 
> Thanks in advance and have a great WE ahead,
> Giulio
> 
> Il giorno sab 2 apr 2022 alle ore 15:03 Jacques Le Roux <
> jacques.le.r...@les7arts.com> ha scritto:


> [...]

[jira] [Closed] (OFBIZ-12183) Groovy script Product.groovy: java.util.NoSuchElementException

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12183.

Resolution: Cannot Reproduce

Closing since not reproducible.

Thanks

> Groovy script Product.groovy: java.util.NoSuchElementException 
> ---
>
> Key: OFBIZ-12183
> URL: https://issues.apache.org/jira/browse/OFBIZ-12183
> Project: OFBiz
>  Issue Type: Bug
>  Components: ecommerce, order
>Affects Versions: Release Branch 18.12, Trunk, 17.12.05, Upcoming Branch
> Environment: Linux/Ubuntu 16.04, Linux/Ubuntu 18.04, OFBiz v13.07.03
>Reporter: Giulio Speri
>Assignee: Nicolas Malin
>Priority: Critical
> Attachments: NoSuchElementException_Productgroovy.jpeg
>
>
> Strange issue happens randomly (it seems) while loading ecommerce product 
> detail page and the groovy script Product.groovy 
> (order/webapp/ordermgr/WEB-INF/actions/entry/catalog/) is run.
> The groovy script is loaded in the screen "product".
> The error showed is kind of java.util.NoSuchElementException and I think that 
> could be something related to session/request attributes, since this could be 
> avoided with an incognito navigation session.
> I saw this error a couple of times during local development also and I could 
> pass over it by manually deleting browser session cookies.
> Unfortunately I was not able to reproduce it yet, so I cannot add more 
> details except hypothesis.
> I also post here a screenshot of the error.
>  
> !NoSuchElementException_Productgroovy.jpeg!  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Closed] (OFBIZ-12612) Update sshd dependency and implementation

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne closed OFBIZ-12612.

Fix Version/s: 22.01.01
   Resolution: Fixed

This was commited in release22 since fixed an implementation issue.

> Update sshd dependency and implementation 
> --
>
> Key: OFBIZ-12612
> URL: https://issues.apache.org/jira/browse/OFBIZ-12612
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: 22.01.01, Upcoming Branch
>
>
> Updating sshd library used by SshFtpClient feature.
> In a customer project, we found out that the current implementation under 
> heavy usage leads to redundant thread creation.
> This patch update the implementation using the last revision of the sshd mina 
> librairy.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (OFBIZ-12612) Update sshd dependency and implementation

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12612:
-
Fix Version/s: Upcoming Branch

> Update sshd dependency and implementation 
> --
>
> Key: OFBIZ-12612
> URL: https://issues.apache.org/jira/browse/OFBIZ-12612
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Updating sshd library used by SshFtpClient feature.
> In a customer project, we found out that the current implementation under 
> heavy usage leads to redundant thread creation.
> This patch update the implementation using the last revision of the sshd mina 
> librairy.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (OFBIZ-12612) Update sshd dependency and implementation

[Gil Portenseigne (Jira)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gil Portenseigne updated OFBIZ-12612:
-
Affects Version/s: Upcoming Branch

> Update sshd dependency and implementation 
> --
>
> Key: OFBIZ-12612
> URL: https://issues.apache.org/jira/browse/OFBIZ-12612
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Upcoming Branch
>    Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
>Priority: Major
>
> Updating sshd library used by SshFtpClient feature.
> In a customer project, we found out that the current implementation under 
> heavy usage leads to redundant thread creation.
> This patch update the implementation using the last revision of the sshd mina 
> librairy.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (OFBIZ-12612) Update sshd dependency and implementation

[Gil Portenseigne (Jira)]

Gil Portenseigne created OFBIZ-12612:


 Summary: Update sshd dependency and implementation 
 Key: OFBIZ-12612
 URL: https://issues.apache.org/jira/browse/OFBIZ-12612
 Project: OFBiz
  Issue Type: Improvement
Reporter: Gil Portenseigne
Assignee: Gil Portenseigne


Updating sshd library used by SshFtpClient feature.

In a customer project, we found out that the current implementation under heavy 
usage leads to redundant thread creation.

This patch update the implementation using the last revision of the sshd mina 
librairy.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Gil Portenseigne]

I do not remember doing such :)

Gil

On Wed, Mar 23, 2022 at 07:13:02PM +0100, Jacques Le Roux wrote:
> Ah forgot, did you fix the warnings?
> 
> Le 23/03/2022 à 19:09, Jacques Le Roux a écrit :
> > Great, thanks Gil!
> > 
> > Le 23/03/2022 à 18:15, Gil Portenseigne a écrit :
> > > Hello Jacques,
> > > 
> > > We have some production server based on 18.12, with java 11.
> > > 
> > > It is working fine.
> > > 
> > > Gil
> > > On Wed, Mar 23, 2022 at 05:58:25PM +0100, Jacques Le Roux wrote:
> > > > BTW,
> > > > 
> > > > Is there someone who is already using Java 11 with 18.12?
> > > > 
> > > > TIA
> > > > 
> > > > Jacques
> > > > 
> > > > Le 23/03/2022 à 16:24, Jacques Le Roux a écrit :
> > > > > Hi Michael,
> > > > > 
> > > > > I don't remember clearly why I had that in mind. I have just
> > > > > tried to run current 18.12 with Java 11 and so far it seems
> > > > > OK. I'll check that better...
> > > > > 
> > > > > Nevertheless, I'll already ask to install both Java 8 and 11 on the 
> > > > > new VM (nothing started yet).
> > > > > 
> > > > > Thanks for the suggestion.
> > > > > 
> > > > > Jacques
> > > > > 
> > > > > Le 18/03/2022 à 12:55, Jacques Le Roux a écrit :
> > > > > > Hi Michael,
> > > > > > 
> > > > > > I suggest to tackle that, including the necessary on the VM, when 
> > > > > > we will effectively switch 22.01 to JDK 11
> > > > > > 
> > > > > > Jacques
> > > > > > 
> > > > > > Le 18/03/2022 à 12:03, Michael Brohl a écrit :
> > > > > > > Hi Jacques,
> > > > > > > 
> > > > > > > should we not also have a VM supporting Java 11 for the 22.01 
> > > > > > > release branch?
> > > > > > > 
> > > > > > > +1 for the rest of the specifications
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 
> > > > > > > Michael Brohl
> > > > > > > 
> > > > > > > ecomify GmbH - www.ecomify.de
> > > > > > > 
> > > > > > > 
> > > > > > > Am 18.03.22 um 11:46 schrieb Jacques Le Roux:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Good news, demos will soon be back :).
> > > > > > > > 
> > > > > > > > Greg asked me to provide specs for a new OFBIZ-VM, I guess 
> > > > > > > > OFBIZ-VM4.
> > > > > > > > 
> > > > > > > > If nobody is against Monday I'll ask for the same than 
> > > > > > > > OFBIZ-VM3 (JDK 8, 8GB RAM, letsencrypt). I guess it will be 
> > > > > > > > Ubuntu again.
> > > > > > > > 
> > > > > > > > JDK8 because it will still need to support 18.12 branch, 8GM 
> > > > > > > > RAM has proven to be good enough for 3 demos so far.
> > > > > > > > 
> > > > > > > > What will change is the replacement of
> > > > > > > > https://demo-old.ofbiz.apache.org/
> > > > > > > > by
> > > > > > > > https://demo-next.ofbiz.apache.org/
> > > > > > > > 
> > > > > > > > https://demo-stable.ofbiz.apache.org/
> > > > > > > > and
> > > > > > > > https://demo-trunk.ofbiz.apache.org/
> > > > > > > > will stay of course.
> > > > > > > > 
> > > > > > > > I have things almost ready at 
> > > > > > > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup
> > > > > > > > 
> > > > > > > > Jacques
> > > > > > > > 


signature.asc
Description: PGP signature

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Gil Portenseigne]

Hello Jacques, 

We have some production server based on 18.12, with java 11.

It is working fine.

Gil
On Wed, Mar 23, 2022 at 05:58:25PM +0100, Jacques Le Roux wrote:
> BTW,
> 
> Is there someone who is already using Java 11 with 18.12?
> 
> TIA
> 
> Jacques
> 
> Le 23/03/2022 à 16:24, Jacques Le Roux a écrit :
> > Hi Michael,
> > 
> > I don't remember clearly why I had that in mind. I have just tried to run 
> > current 18.12 with Java 11 and so far it seems OK. I'll check that better...
> > 
> > Nevertheless, I'll already ask to install both Java 8 and 11 on the new VM 
> > (nothing started yet).
> > 
> > Thanks for the suggestion.
> > 
> > Jacques
> > 
> > Le 18/03/2022 à 12:55, Jacques Le Roux a écrit :
> > > Hi Michael,
> > > 
> > > I suggest to tackle that, including the necessary on the VM, when we will 
> > > effectively switch 22.01 to JDK 11
> > > 
> > > Jacques
> > > 
> > > Le 18/03/2022 à 12:03, Michael Brohl a écrit :
> > > > Hi Jacques,
> > > > 
> > > > should we not also have a VM supporting Java 11 for the 22.01 release 
> > > > branch?
> > > > 
> > > > +1 for the rest of the specifications
> > > > 
> > > > Thanks,
> > > > 
> > > > Michael Brohl
> > > > 
> > > > ecomify GmbH - www.ecomify.de
> > > > 
> > > > 
> > > > Am 18.03.22 um 11:46 schrieb Jacques Le Roux:
> > > > > Hi,
> > > > > 
> > > > > Good news, demos will soon be back :).
> > > > > 
> > > > > Greg asked me to provide specs for a new OFBIZ-VM, I guess OFBIZ-VM4.
> > > > > 
> > > > > If nobody is against Monday I'll ask for the same than OFBIZ-VM3 (JDK 
> > > > > 8, 8GB RAM, letsencrypt). I guess it will be Ubuntu again.
> > > > > 
> > > > > JDK8 because it will still need to support 18.12 branch, 8GM RAM has 
> > > > > proven to be good enough for 3 demos so far.
> > > > > 
> > > > > What will change is the replacement of
> > > > > https://demo-old.ofbiz.apache.org/
> > > > > by
> > > > > https://demo-next.ofbiz.apache.org/
> > > > > 
> > > > > https://demo-stable.ofbiz.apache.org/
> > > > > and
> > > > > https://demo-trunk.ofbiz.apache.org/
> > > > > will stay of course.
> > > > > 
> > > > > I have things almost ready at 
> > > > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup
> > > > > 
> > > > > Jacques
> > > > > 


signature.asc
Description: PGP signature

Re: Welcome to Nicola Mazzoni and Giulio Speri as new committers

[Gil Portenseigne]

Congratulations, Welcome !

Gil
On Mon, Mar 21, 2022 at 09:26:16PM +0100, Jacopo Cappellato wrote:
> The OFBiz PMC has invited Nicola Mazzoni and Giulio Speri as new
> committers and we are glad to announce that they have accepted the
> nomination.
> 
> On behalf of the OFBiz PMC, welcome on board!


signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.05 (second attempt)

[Gil Portenseigne]

+1,

Verifying files...
sha check of file: apache-ofbiz-18.12.05.zip
Using sha file: apache-ofbiz-18.12.05.zip.sha512
apache-ofbiz-18.12.05.zip: F7952ED5 C794357F E730C7DE 404B0B8B 7A123A89 
9DA7A1C1 4D0136ED 64D6FAA3 7645018E 9EDE93FB 88FC27A3 D718DA64 E8636541 
334583ED 606F5516 6D653B2C
apache-ofbiz-18.12.05.zip: F7952ED5 C794357F E730C7DE 404B0B8B 7A123A89 
9DA7A1C1 4D0136ED 64D6FAA3 7645018E 9EDE93FB 88FC27A3 D718DA64 E8636541 
334583ED 606F5516 6D653B2C
sha checksum OK

PGP sigs and integration test ok.

Thanks,

Gil

On Sun, Jan 02, 2022 at 12:29:37PM +0100, Jacopo Cappellato wrote:
> This is the second vote thread to release a new bug fix release for the
> release18.12 branch. This new release, "Apache OFBiz 18.12.05"
> supersedes all the previous releases from the same branch.
> 
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> 
> and are:
> * apache-ofbiz-18.12.05.zip
> * KEYS: text file with keys
> * apache-ofbiz-18.12.05.zip.asc: the detached signature file
> * apache-ofbiz-18.12.05.zip.sha512: checksum file
> 
> Please download and test the zip file and its signatures (for
> instructions on testing the signatures see [*]).
> 
> Vote:
> 
> [ +1] release as Apache OFBiz 18.12.05
> [ -1] do not release
> 
> For more details about this process please read [**].
> [*]
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Votingonarelease
> [**] http://www.apache.org/foundation/voting.html


signature.asc
Description: PGP signature

[jira] [Commented] (OFBIZ-9498) Improve DevOps using environment variable configuration

[Gil Portenseigne (Jira)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466789#comment-17466789
 ] 

Gil Portenseigne commented on OFBIZ-9498:
-

Hello [~ieugen] ,

Thanks for your review, I work with [~marco_adeti] whom i gave the relay to 
animate the subject. He should make a first proposal about a new idea, in some 
times.

About the current patch, no progress yet, it is usable, and used in several 
customer project in our side, feel free to experience.

> Improve DevOps using environment variable configuration
> ---
>
> Key: OFBIZ-9498
> URL: https://issues.apache.org/jira/browse/OFBIZ-9498
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>    Assignee: Gil Portenseigne
>Priority: Minor
> Attachments: OFBIZ-9498.patch
>
>
> Discussed in thread : https://s.apache.org/Mh3q
> This Jira will present the improvment proposal giving a way to configure 
> OFBiz using environment variable.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [Conclusion] PartyRole usage in OFBiz

[Gil Portenseigne]

Hello Pierre,

Inline,

On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:
> Hi Gil, All,
> 
> My apologies, but I have to object to this and for the following reasoning:
> Objections to pursuing improvements to the entity definition (for
> PartyRole) and subsequent addressing front-end issues (screens/forms,
> requests, services etc) for that and other entities impacted were raised,
> before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole was
> brought forward now 4 days ago.

I'm aware about this page and discussion, if i'm not wrong, it is not
about adding lifespan into PartyRole entity. That is the point I wanted
to clarify. I'm not contesting this improvement, that can continue in a
dedicated thread.

If you think that subject is common please clarify to let us take
position on the PartyRole case (the only one I want to tackle at the
moment)

> 
> That page defines the requirements for any and all EntityNameRole entity,
> including PartyRole. And the validity of what was stated there has not been
> contested up to now. Not even by those objecting to changes to PartyRole
> (as it is included in the page) before the date/time of the page, and who
> have remained silent since the availability of the page. I wanted to wait a
> bit longer, so that every contributor (and other readers of the dev ml)
> could have an informed opinion, before suggesting to claim consensus on
> that. But alas...

I did not gave date on purpose, there is no hurry, it was a way to
recenter the discussion about this specific case.
> 
> So it stands to reason that getting current existing and failing
> EntityNameRole entities (including the PartyRole entity) compliant is
> implied and thus warranted. And thus tickets can stay as they are. Just the
> order of improvements coming in is a concern that needs to be addressed
> when they come in. And if such concerns can be addressed and eliminated
> beforehand, so much the better.
> 
> Furthermore, one key aspect I would like to mention here. You mentioned in
> your comment (see [1]): 'The current applications IMO are not meant to be
> used as is'.
> This is a very wrong point of view, as the many users/contributors in user
> ml see differently.

That is mine, and claiming it is wrong because others see it differently
is not a valid argument to me. 

Claiming that in webtools and partymgr there can be FK errors while
deleting PartyRole, is IMO not a good argument since those component are
*technical* ones that should not be used by *non technical* end users.

The idea is not the same for more business component like HR for
example, where I agree should be more usable for business end user.

> Otherwise they would not raise a thread about the
> workings of OFBiz, about functionalities not being good enough. Or a ticket
> in JIRA. They expect OFBiz as a business solutions to be usable as is, as a
> minimal viable product (MVP). They don't expect it to be perfect when they
> start using it. They'll trust that it will come along in due time.  And
> they also don't expect it to have all the bells and whistles a particular
> developer thinks necessary (while adding no value to the user). But, any
> improvement brought forward to benefit all can/should go in. That is what
> they expect.

> And integrators downstream can take that and enhance for their own audience
> (current and future) as they see fit. It is not up to the integrators (as
> you proclaimed in the same posting: 'It is our choices as Integrators to
> decide') to decide what goes into OFBiz that works for all users, not just
> their own clients. System integrators don't contribute to an project to the
> ASF. Even if they would be able to do so, at the end the using company
> decides).
You are interpreting my words. I was not talking about contribution, but
about integrators using Apache OFBiz for their customer. The decision I
was mentioning was about how they design their product to fill the need
for their customer, where there is not truth but choice to be made.

I remember discussion with you and others in Budapest (old good time)
that the applications are too big, present many features that
demonstrate the power of OFBiz, and this fact leads to being hardly
usable without customization. 
In my experience, anytime I redevelop specific plugins for my end user
to simplify to their needs, that is the choice I made as an integrator
human being (not my company).

> We need to work on that perception of contributors with privileges, as it
> seems that this mindset (Integrators decide) is dictates the direction of
> this project.

I never meant that, i'm sure you know it, that is kinda rude.

Can we please focus on the subject ?

Thanks,

Gil



signature.asc
Description: PGP signature