Re: Blacklist and whitelist replacements
Hi, It's nice works Jacques to replace the blacklist and whitelist. For master and slave, regard to french history, I have clearly a problem with that. For explanation, the french society grew by the slave exploit called "La traite des noires" during the 16th, with men like Colbert that legalize and encourage this slaughter. ... No comment ... It's a shame for me that hurt my heart each time I remember the origin of this for black people on usa, and I clearly understand that this word can be hurt with a passive "insinuation" today. I will check the different usage of master in our code. After check after filtering all js lib, fo.ftl element as spotted Michael, exclude "master card", we have few occurrences that we can change (like master list). I can work on it. Nicolas On 30/01/2021 10:52, Jacques Le Roux wrote: > Hi, > > After a discussion between ASF members, I saw that an effort has been > done by Infra, and I guess in some TLPs, to replace some connoted > words like blacklist and whitelist. > > We have not much occurrences of these words, so I suggest that we > replace blacklist and whitelist list respectively by denylist and > allowlist as suggested by > https://english.stackexchange.com/questions/51088/alternative-terms-to-blacklist-and-whitelist#answer-51104 > > > There is also this article: > https://developer-tech.com/news/2020/jun/15/github-replace-slavery-terms-master-whitelist/ > > We have only 1 occurrence of slave in our own code, that would be > easy. For master it's more annoying 1771 occurrences, so that would > need a review. > > What do you think? > > Jacques >
Re: JFrog to shut down jcenter
Hi Michael, On 15/02/2021 22:12, Michael Brohl wrote: > Hi Nicolas, > > I thought that we are restricted to the Gradle version for 17.12, aren‘t we? Yes we said that. The rules are the better help to follow the path and when it come to hard to follow perhaps it's time to share for an alternative way. > If not I think it‘s easy to upgrade Gradle to just the first version which > supports metadataSources and proceed from there. I think it's a good compromise to try :) Nicolas > > Thanks, > Michael > >> Am 15.02.2021 um 19:08 schrieb Nicolas Malin : >> >> Hi Michel, >> >> Thanks for your works, I will check If I found a solution with Gradle >> 3.2.1. I keep in my that a solution would be increase the Gradle >> version for the 17.12 >> >> Nicolas >> >>> On 14/02/2021 16:51, Michael Brohl wrote: >>> For those who do not read the notifications for >>> https://issues.apache.org/jira/browse/OFBIZ-12171 I'd like to reach >>> you here too. >>> >>> I've already done the migration for trunk (committed) and r18.12 >>> (PR's, to be committed in the next days). >>> >>> I've also started with the migration for 17.12, which will be tougher >>> because of the Gradle old version used there. There is no >>> metadataSources API to specify to pull a jar without a pom, which is >>> used for the flute dependency. >>> >>> Does someone know how to correct a pom in maven central? This is the >>> reason why metadataSources API was used for trunk and r18.12. >>> >>> Or does someone know a way to pull artefacts/jars from a repository >>> without a valid pom in Gradle 3.2.1? >>> >>> Any help is appreciated, thanks! >>> >>> Michael Brohl >>> >>> ecomify GmbH - www.ecomify.de >>> >>> Am 10.02.21 um 16:44 schrieb Michael Brohl: Ah, yes, thanks Jacques. See https://issues.apache.org/jira/browse/OFBIZ-12171 for the issue and links to the pull requests. Thanks, Michael Am 10.02.21 um 16:22 schrieb Jacques Le Roux: > Le 10/02/2021 à 11:06, Michael Brohl a écrit : >> I think I've got it solved for trunk, please see >> https://issues.apache.org/jira/browse/INFRA-21376 and the linked >> pull requests there. > I guess you mean OFBIZ-12171 rather no? > > Jacques >
Re: JFrog to shut down jcenter
Hi Nicolas, I thought that we are restricted to the Gradle version for 17.12, aren‘t we? If not I think it‘s easy to upgrade Gradle to just the first version which supports metadataSources and proceed from there. Thanks, Michael > Am 15.02.2021 um 19:08 schrieb Nicolas Malin : > > Hi Michel, > > Thanks for your works, I will check If I found a solution with Gradle > 3.2.1. I keep in my that a solution would be increase the Gradle > version for the 17.12 > > Nicolas > >> On 14/02/2021 16:51, Michael Brohl wrote: >> For those who do not read the notifications for >> https://issues.apache.org/jira/browse/OFBIZ-12171 I'd like to reach >> you here too. >> >> I've already done the migration for trunk (committed) and r18.12 >> (PR's, to be committed in the next days). >> >> I've also started with the migration for 17.12, which will be tougher >> because of the Gradle old version used there. There is no >> metadataSources API to specify to pull a jar without a pom, which is >> used for the flute dependency. >> >> Does someone know how to correct a pom in maven central? This is the >> reason why metadataSources API was used for trunk and r18.12. >> >> Or does someone know a way to pull artefacts/jars from a repository >> without a valid pom in Gradle 3.2.1? >> >> Any help is appreciated, thanks! >> >> Michael Brohl >> >> ecomify GmbH - www.ecomify.de >> >> >>> Am 10.02.21 um 16:44 schrieb Michael Brohl: >>> Ah, yes, thanks Jacques. >>> >>> See https://issues.apache.org/jira/browse/OFBIZ-12171 for the issue >>> and links to the pull requests. >>> >>> Thanks, >>> >>> Michael >>> >>> >>> Am 10.02.21 um 16:22 schrieb Jacques Le Roux: Le 10/02/2021 à 11:06, Michael Brohl a écrit : > I think I've got it solved for trunk, please see > https://issues.apache.org/jira/browse/INFRA-21376 and the linked > pull requests there. I guess you mean OFBIZ-12171 rather no? Jacques
Re: JFrog to shut down jcenter
Hi Michel, Thanks for your works, I will check If I found a solution with Gradle 3.2.1. I keep in my that a solution would be increase the Gradle version for the 17.12 Nicolas On 14/02/2021 16:51, Michael Brohl wrote: > For those who do not read the notifications for > https://issues.apache.org/jira/browse/OFBIZ-12171 I'd like to reach > you here too. > > I've already done the migration for trunk (committed) and r18.12 > (PR's, to be committed in the next days). > > I've also started with the migration for 17.12, which will be tougher > because of the Gradle old version used there. There is no > metadataSources API to specify to pull a jar without a pom, which is > used for the flute dependency. > > Does someone know how to correct a pom in maven central? This is the > reason why metadataSources API was used for trunk and r18.12. > > Or does someone know a way to pull artefacts/jars from a repository > without a valid pom in Gradle 3.2.1? > > Any help is appreciated, thanks! > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 10.02.21 um 16:44 schrieb Michael Brohl: >> Ah, yes, thanks Jacques. >> >> See https://issues.apache.org/jira/browse/OFBIZ-12171 for the issue >> and links to the pull requests. >> >> Thanks, >> >> Michael >> >> >> Am 10.02.21 um 16:22 schrieb Jacques Le Roux: >>> Le 10/02/2021 à 11:06, Michael Brohl a écrit : I think I've got it solved for trunk, please see https://issues.apache.org/jira/browse/INFRA-21376 and the linked pull requests there. >>> I guess you mean OFBIZ-12171 rather no? >>> >>> Jacques >>>
Re: GString to String
I'm agree Jacques with that.
Some time on specific customer code I was confronted to bad gstring
conversion on groovy service because I forgot that "this ${code}" isn't
a string in groovy !
:)
Nicolas
On 13/02/2021 13:48, Jacques Le Roux wrote:
> Hi,
>
> I spotted this error in log
>
> 2021-02-13 10:17:03,503 |jsse-nio-8443-exec-8
> |Converters |W| *** No converter found, converting
> from org.codehaus.groovy.runtime.GStringImpl to java.lang.String.
> Please report this message to the developer community s
> o a suitable converter can be created. ***
> 2021-02-13 10:17:03,503 |jsse-nio-8443-exec-8
> |ObjectType |E| null
> java.lang.ClassNotFoundException: No converter found for
> org.codehaus.groovy.runtime.GStringImpl->java.lang.String
> at
> org.apache.ofbiz.base.conversion.Converters.getConverter(Converters.java:119)
> ~[main/:?]
> at
> org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:328)
> [main/:?]
> at
> org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:256)
> [main/:?]
> at
> org.apache.ofbiz.base.util.ObjectType.simpleTypeOrObjectConvert(ObjectType.java:375)
> [main/:?]
> at
> org.apache.ofbiz.entity.GenericEntity.set(GenericEntity.java:550)
> [main/:?]
> at
> org.apache.ofbiz.entity.GenericEntity.set(GenericEntity.java:502)
> [main/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_202]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_202]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_202]
> at java.lang.reflect.Method.invoke(Method.java:498)
> ~[?:1.8.0_202]
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
> [groovy-2.5.11.jar:2.5.11]
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> [groovy-2.5.11.jar:2.5.11]
> at
> groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2754)
> [groovy-2.5.11.jar:2.5.11]
> at
> groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3809)
> [groovy-2.5.11.jar:2.5.11]
> at
> org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:217)
> [groovy-2.5.11.jar:2.5.11]
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:496)
> [groovy-2.5.11.jar:2.5.11]
> at
> DataServices.saveLocalFileDataResource(DataServices.groovy:280)
> [script:?]
> at DataServices$saveLocalFileDataResource.callCurrent(Unknown
> Source) [script:?]
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> [groovy-2.5.11.jar:2.5.11]
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:156)
> [groovy-2.5.11.jar:2.5.11]
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:168)
> [groovy-2.5.11.jar:2.5.11]
> at
> DataServices.attachUploadToDataResource(DataServices.groovy:191)
> [script:?]
> [...]
> 2021-02-13 10:17:03,507 |jsse-nio-8443-exec-8
> |ObjectType |I| No special conversion required for
> org.codehaus.groovy.runtime.GStringImpl to String, returning
> object.toString().
>
> To prevent this message, I propose to bypass GString to String
> conversion.
>
> What do you think?
>
> Jacques
>
Re: FYI: 18.12.01 release and more
Hi, +1, Same here, this plan feel good. Nicolas On 11/02/2021 12:28, Pawan Verma wrote: > Hi Everyone, > > +1 for release 17.12.06 asap. > +1 for release 18.12 asap. > > We should start migrating the trunk to JDK11 then create R21 asap. > Stabilize and release R21 maybe in 2021 itself or in the first half of 2022 > sooner the better. >
Re: buildbot exception in on ofbizBranch18Framework
... fixed. Michael Am 15.02.21 um 18:38 schrieb Michael Brohl: checking... Michael Am 15.02.21 um 18:26 schrieb build...@apache.org: The Buildbot has detected a build exception on builder ofbizBranch18Framework while building ofbiz-framework. Full details are available at: https://ci.apache.org/builders/ofbizBranch18Framework/builds/450 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'onBranch18FrameworkCommit' triggered this build Build Source Stamp: [branch release18.12] f9fc00ad3b556e14c812ffa7033fe5be65884519 Blamelist: Sebastian Berg BUILD FAILED: exception shell upload Sincerely, -The Buildbot
Re: buildbot exception in on ofbizBranch18Framework
checking... Michael Am 15.02.21 um 18:26 schrieb build...@apache.org: The Buildbot has detected a build exception on builder ofbizBranch18Framework while building ofbiz-framework. Full details are available at: https://ci.apache.org/builders/ofbizBranch18Framework/builds/450 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'onBranch18FrameworkCommit' triggered this build Build Source Stamp: [branch release18.12] f9fc00ad3b556e14c812ffa7033fe5be65884519 Blamelist: Sebastian Berg BUILD FAILED: exception shell upload Sincerely, -The Buildbot
Re: Default ordering of webapps titles in main menu
Hi, As you may have seen, I have continued the discussion on user ML: https://markmail.org/message/r65p22uinzabqppc Also Michael questioned my commit in R18[1] since it's only an improvement, what do you think? [1] https://s.apache.org/32w0t Jacques Le 08/10/2020 à 12:34, Jacques Le Roux a écrit : Hi, Today Deepak answered on user ML https://markmail.org/message/syzvyyueheejyyce how to order webapps titles in main menu. BTW OOTB it would work for
Re: buildbot exception in on ofbizTrunkFramework
Fixed Le 14/02/2021 à 21:19, Jacques Le Roux a écrit : OK I'll fix that later (soon)... Le 14/02/2021 à 19:38, build...@apache.org a écrit : The Buildbot has detected a build exception on builder ofbizTrunkFramework while building ofbiz-framework. Full details are available at: https://ci.apache.org/builders/ofbizTrunkFramework/builds/2105 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' triggered this build Build Source Stamp: [branch trunk] 568ac8927bd74d83cd099a5d0fd59dd06a595b26 Blamelist: Jacques Le Roux BUILD FAILED: exception build upload test-results part 1 Sincerely, -The Buildbot
