Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
+1 Thanks, Gil On 03/09/2024 15:21, Nicolas Malin wrote: > Hello, > > After going through this thread [1], I propose to go ahead with the > creation of the `release24` branch in a few weeks, and the release of > the next official version 2 or 3 weeks later. > > Why: > * We've decided to leave release22.01 unpublished. > * The trunk has been stable for a long time (integration tests are > working well). > * The current version is over 6 years old > * If we wait another year for stabilization, there's a chance that a > lot of work-in-progress will be added, and as with release 22, we'll > probably miss the release stage. > * We have a lot of work to do on the trunk :D > > If there are no major objection, I'll put the release24 branch > creation to the vote in a few days. > > Nicolas > > [1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1 >
Re: [VOTE] Apache OFBiz 18.12.10
+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
IDEA plugin contribution
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.
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 p
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
+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
Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
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&revision=1298908
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
+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&focusedCommentId=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"
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&revision=1298908
Re: Codenarc integration process
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: [VOTE] Apache OFBiz 18.12.07
+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
Re: Codenarc integration process
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
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
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: Welcome to Leila Mekika as new committer
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: Codenarc integration, rules to use.
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.
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 - Che
Re: Codenarc integration, rules to use.
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
Re: Codenarc integration, rules to use.
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
Re: Codenarc integration, rules to use.
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
Codenarc integration, rules to use.
s 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. | ++-+ I think that if someone want to express an opposition about applying one of the above rule, i would be great to express it and discuss it here. My opinion is that it could be nice to adopt every rules, to respect standard best practice. Even if it implies lot of code changes. Thanks in advance for your feedback. Regards, Gil signature.asc Description: PGP signature
Re: "New commiter first steps" wiki page proposal
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 > <https://cwiki.apache.org/confluence/x/nBihD> > > 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: > [...]
Re: [INFRA-22722] Restart the ofbiz-vm3 demos server
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
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
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)
+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
Re: [Conclusion] PartyRole usage in OFBiz
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
[Conclusion] PartyRole usage in OFBiz
Hello, I will try to summarize the ongoing thread, to produce a conclusion or potential plan. Sorry in advance, if I forgot some points. About the improvement of adding lifespan in PartyRole entity, the "Won't do" seems to get the consensus, since this improvement do not follow logical purpose (might for audit), and will introduce regressions and bugs risks if implemented. The discussion went to a new subjects, like using PartyRelationship for party selection screens. Opinion about removing PartyRole FK from EntityRole entities has been expressed. Those both topics can be lead into separate thread if needed, to let anyone envision it without being polluted by the previous discussion in the thread. If no one object I will close Jira about PartyRole lifespan. Thanks for your sharing, and Regards. Gil signature.asc Description: PGP signature
Re: [VOTE] Apache OFBiz 18.12.02 (second attempt)
+1 Thanks On Tue, Nov 16, 2021 at 05:26:52PM +0100, Jacopo Cappellato wrote: > This is the second vote thread to publish "Apache OFBiz 18.12.02", the > second 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.02.zip > * KEYS: text file with keys > * apache-ofbiz-18.12.02.zip.asc: the detached signature file > * apache-ofbiz-18.12.02.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.02 > [ -1] do not release > > This vote will be open for 5 days. > > For more details about this process please refer to > http://www.apache.org/foundation/voting.html > > Best Regards, > > Jacopo signature.asc Description: PGP signature
Re: PartyRole usage in OFBiz
I will try to explain better With OFBiz you could create minimalistic application where you could define roles to a party to make them appear in one dropdown for a specific purpose. What I wanted to show is that through pragmatism, basic usage of PartyRole can exist and be sufficient. But whereas a business need indicates that there is retirement of an actor from a particular role, for me, then context "EntityNameRole" fits for this. Thus I agree with PartyRelationship usage. In partyMgr component, when managing party relationships and party role, since it is more like a technical component, I do not see how we can improve the screens and avoid having technical error like partyRole FK constraint. And moreover, it is nice like this to me. For business oriented component, like HR, the choice of roles managements process should be made, and if I understand well that the goal of OFBIZ-5827. I hope it is clear Gil Le lun. 15 nov. 2021 à 1:25 pm, Jacques Le Roux a écrit : Hi Gil, Inline... Le 15/11/2021 à 10:36, gil a écrit : Hello, The current applications IMO are not meant to be used as it, but are presenting existing features. So there are many design flaws that exists in the current states of the application (leads to fk constraint error messages when deleting partyRole or creating partyRel). The example of having only a partyRole defined for an actor to be selected can be *sufficient* in one implementation Sorry, I'm not sure what that means, could you explain a bit more? TIA Having the need to expire role association implies, for me, to have it associated within a context (WorkEffort, PartyRel, etc.) which OFBIZ-5827 is one possibility. That makes sense and would prevent to remove PKs to PartyRole from EntityNameRole relations. But do we really need that? Should we not rather concentrate on PartyRelationShip. For instance we can't assign a role to a party with a relation to an organisation (for OFBIz implementation where there is several organisations). PartyRelationShip allows that. It is our choices as Integrators to decide and customize application to use `ensurePartRole` when it is needed, or to lookup for the good configured party the way it is the best for our case. Sure, but what do you mean by that? To not remove things in model, services, UI, etc? In other word, Jacques I second your proposal, that seems the consensus we could agree on. Thanks, but it's a bit confuse to me, detailing your proposition would help. TIA Jacques Thanks, Gil Le lun. 15 nov. 2021 à 8:04 am, Jacques Le Roux mailto:jacques.le.r...@les7arts.com>> a écrit : Le 13/11/2021 à 19:26, Jacques Le Roux a écrit : Jacopo made an interesting comment at: <<https://s.apache.org/6s8lr>> that: <facilitated by one approach and made more difficult by the other, to both ways of interpreting PartyRole records. The current approach, implemented in many ootb applications, as Michael Brohl has pointed out, is to interpret the PartyRole records as all the roles the party actually plays. The other approach, that is the one advocated by Pierre Smits, is to interpret the PartyRole records as the roles the party can play.>> Hi Jacopo, All, Thinking about it, is there not a contradiction between Michael's vision (actually also how it was also historically envisioned by the founders) and the fact that we are able to create/edit PartyRoles in party component? Hence the creation of OFBIZ-5980 "Have the ability to revoke (expire) roles of a party", OFBIZ-12370 "InvoiceRole: impossible combination of party and role selectable: leads to error" and all related issues, It seems to me that OFBIZ-5827 "Have party selection in screens based on relation(s) in stead of role" and all related issues fits more. Note that all is Pierre's work. That's the Gordian node I speak about. I think we have already almost decided how to cut it: OFBIZ-5827 way rather than OFBIZ-5980 one. So we should tackle OFBIZ-5827 and all related issues and close OFBIZ-5980 and all related issue after carefully reviewing them Nobody objects? Jacques Le lun. 15 nov. 2021 à 1:25 pm, Jacques Le Roux a écrit : Hi Gil, Inline... Le 15/11/2021 à 10:36, gil a écrit : Hello, The current applications IMO are not meant to be used as it, but are presenting existing features. So there are many design flaws that exists in the current states of the application (leads to fk constraint error messages when deleting partyRole or creating partyRel). The example of having only a partyRole defined for an actor to be selected can be *sufficient* in one implementation Sorry, I'm not sure what that means, could you explain a bit more? TIA Having the need to expire role association implies, for me, to have it associated within a context (WorkEffort, Par
RE: Welcome Wiebke Pätzold as new committer!
Congratulations Wiebke ! Regards, Gil Le lun. 15 nov. 2021 à 2:09 pm, Swapnil Shah a écrit : Many congratulations and welcome aboard Weibke !! Regards, Swapnil -Original Message- From: Jacques Le Roux <mailto:jacques.le.r...@les7arts.com>> Sent: 29 October 2021 20:18 To: dev@ofbiz.apache.org <mailto:dev@ofbiz.apache.org> Subject: Re: Welcome Wiebke Pätzold as new committer! Welcome aboard Wiebke, Your work is much appreciated! Jacques Le 27/10/2021 à 12:57, Aditya Sharma a écrit : The OFBiz PMC has invited Wiebke to become a new committer and we are pleased to announce that she has accepted the nomination. Wiebke has been an active contributor to Apache OFBiz since February 2020, and has made some significant contributions on minilang migration. She has also been helping out Michael with Apache OFBiz blogs. Thank you Wiebke for your valuable contributions so far and congratulations for your new role! Welcome aboard! Thanks and Regards, Aditya Sharma
Re: PartyRole usage in OFBiz
Hello, The current applications IMO are not meant to be used as it, but are presenting existing features. So there are many design flaws that exists in the current states of the application (leads to fk constraint error messages when deleting partyRole or creating partyRel). The example of having only a partyRole defined for an actor to be selected can be *sufficient* in one implementation Having the need to expire role association implies, for me, to have it associated within a context (WorkEffort, PartyRel, etc.) which OFBIZ-5827 is one possibility. It is our choices as Integrators to decide and customize application to use `ensurePartRole` when it is needed, or to lookup for the good configured party the way it is the best for our case. In other word, Jacques I second your proposal, that seems the consensus we could agree on. Thanks, Gil Le lun. 15 nov. 2021 à 8:04 am, Jacques Le Roux a écrit : Le 13/11/2021 à 19:26, Jacques Le Roux a écrit : Jacopo made an interesting comment at: <https://s.apache.org/6s8lr> that: <facilitated by one approach and made more difficult by the other, to both ways of interpreting PartyRole records. The current approach, implemented in many ootb applications, as Michael Brohl has pointed out, is to interpret the PartyRole records as all the roles the party actually plays. The other approach, that is the one advocated by Pierre Smits, is to interpret the PartyRole records as the roles the party can play.>> Hi Jacopo, All, Thinking about it, is there not a contradiction between Michael's vision (actually also how it was also historically envisioned by the founders) and the fact that we are able to create/edit PartyRoles in party component? Hence the creation of OFBIZ-5980 "Have the ability to revoke (expire) roles of a party", OFBIZ-12370 "InvoiceRole: impossible combination of party and role selectable: leads to error" and all related issues, It seems to me that OFBIZ-5827 "Have party selection in screens based on relation(s) in stead of role" and all related issues fits more. Note that all is Pierre's work. That's the Gordian node I speak about. I think we have already almost decided how to cut it: OFBIZ-5827 way rather than OFBIZ-5980 one. So we should tackle OFBIZ-5827 and all related issues and close OFBIZ-5980 and all related issue after carefully reviewing them Nobody objects? Jacques
PartyRole usage in OFBiz
Hello, I'm starting a new thread to discuss with the community about an Improvement that has been submitted by Pierre Smits [1] This topic has already been discussed in the past [2] and was conclude by a lazy consensus not to implement PartyRole lifespan into OFBiz. Recently, this improvement was discussed again in Jira [3], and partly commited, before being reverted when big blocking side effect where discovered. A more detailed summary has been made by Jacques here [4]. The enhancement is about adding fromDate and thruDate fields onto PartyRole entity, modifying its primary key (fromDate) The fact is that a such big subject need to be addressed with the community consensus, as it is not trivial. Please let us know you thoughts about this task and let's decide, if we need to organize or if we need to close pending Jira with reference to this discussion ? Thanks, Gil [1] https://issues.apache.org/jira/browse/OFBIZ-5959 [2] https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274) [4] https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
Re: [VOTE] Apache OFBiz 18.12.01
+1 Thanks, Gil On Sat, Oct 23, 2021 at 05:08:32PM +0200, Jacopo Cappellato wrote: > This is the vote thread to publish "Apache OFBiz 18.12.01", the first > release from the release17.12 branch. > > The release files can be downloaded from here: > https://dist.apache.org/repos/dist/dev/ofbiz/ > and are: > * apache-ofbiz-18.12.01.zip > * KEYS: text file with keys > * apache-ofbiz-18.12.01.zip.asc: the detached signature file > * apache-ofbiz-18.12.01.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.01 > [ -1] do not release > > This vote will be open for 5 days. > > For more details about this process please refer to > http://www.apache.org/foundation/voting.html > > Best Regards, > > Jacopo signature.asc Description: PGP signature
Re: [apache/ofbiz-framework] Run failed: Java CI with Gradle - trunk (c0f8783)
Hello, I got a notification of CI that use jdk 1.8 for trunk. Is there any action that i can do to configure java 11 or more ? Thanks, Gil On Thu, Sep 23, 2021 at 06:03:33AM -0700, Gil Portenseigne wrote: > [apache/ofbiz-framework] Java CI with Gradle workflow run > > Repository: apache/ofbiz-framework > Workflow: Java CI with Gradle > Duration: 3 minutes and 3.0 seconds > Finished: 2021-09-23 13:03:22 UTC > > View results: > https://github.com/apache/ofbiz-framework/actions/runs/1265900307 > > Jobs: > * build failed (1 annotation) > > -- > You are receiving this because this workflow ran on your branch. > Manage your GitHub Actions notifications: > https://github.com/settings/notifications signature.asc Description: PGP signature
Re: [DISCUSSION] Do we start the R18 publish process ?
+1 Thanks, Gil On Mon, Sep 20, 2021 at 10:13:04AM +0200, Nicolas Malin wrote: > The main is on the title :) > > At this time some issue are always present [1], so we have to decide > whether to launch and move them to the next. > > My feeling is after some time on it, we can go ahead and keep their fix > for the next when it would be possible. > > Nicolas > > -- > logoNrd <https://nereide.fr/> > Nicolas Malin > The apache way <http://theapacheway.com/> : *Charity* Apache’s mission > is providing software for the public good. > informat...@nereide.fr > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54 > > Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way > <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/> signature.asc Description: PGP signature
Re: Freemarker auto-escaping
Hello, I used to define `<#ftl output_format="XML">` on top of ftl files for this purpose. But having this on file extension looks nice to me. Thanks Jacques for the head up. Gil On Wed, Sep 08, 2021 at 02:59:27PM +0200, Jacques Le Roux wrote: > Hi, > > Long ago we opened https://issues.apache.org/jira/browse/OFBIZ-7675 for that > > Few days ago Dániel Dékány (VP and main contributor to Apache Freemarker > project) wrote at FREEMARKER-189 (https://s.apache.org/fitxs): > >< the Manual). [...] Then people can't accidentally forget adding them>> > > I was reluctant do use all auto-escaping features. But I believe we should > follow Forrest Rae > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=fbr%4014x.net>'s > suggestion at OFBIZ-7041 <https://issues.apache.org/jira/browse/OFBIZ-7041> > that we turn Freemarker autoescaping on. Quoting him there: > >< formats. The <#escape> directive has been deprecated. Notice the comment at > the >very end of this page: >"FreeMarker automatically escapes all values printed ... if it's properly > configured (that's the responsibility of the programmers; see here how ><http://freemarker.org/docs/pgui_config_outputformatsautoesc.html>)." >Would be good to turn autoescaping on, and set the configuration to match > .ftl as HTML and .fo.ftl as XML.>> > > I mean the last part of Forrest Rae > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=fbr%4014x.net>'s > proposition, ie : > > 1. removes all "?html" expression and renames all nameIt.ftl files to > nameIt.ftlh > 2. removes all<#escape x as x?xml> ... couples and renames all > nameIt.fo.ftl files to nameIt.fo.ftlx > > I think these changes are safe (to be tested of course). > > What do you think? > > Thanks > > Jacques > signature.asc Description: PGP signature
Groovy integration tests
Hello, Currently using release 18.12 for some project we got the habit to develop using integration test while developing in groovy. For that usage we use mainly : groovy-test-suite That allow coding tests in groovy script that do not need to be compiled for their execution and executing them from webtools [1] (small improvement will be contributed soon), there is no need to reboot the local dev OFBiz instance for each modification in that test. But these type of test has been removed with OFBIZ-11165 [2], while I thinks that these resources are better compiled, during development process, not having to restart OFBiz is nice. So if nobody is against, I will reintroduce it in trunk with a note explaining the `dev` usage. WDYT Regards, Gil [1] https://localhost:8443/webtools/control/TestSuiteInfo [2] https://issues.apache.org/jira/browse/OFBIZ-11165 signature.asc Description: PGP signature
Re: Logical dependency tree for ofbiz components OFBIZ-12309
Hello Eugen, [...] > > I have on my mind to elaborate a framework-core an acceptable minimal > > circular dependencies and some other present as three dependency > > > >* core : common - base - start - entity - service - security - webapp > >* entityext : core > >* datafile: core > >* testtools: core > >* catalina: core > >* widget: core > >* webtools: widget, testtools, datafile, catalina > > > > I know this isn't your final objective but can it be an acceptable spot ? > > Thanks. It's a very good place to start. > We might be able to introduce a 'core' gradle project that contains those > and depend on that one in the others. > > I would move out start module. > It seems to be responsible for starting up the app. > I imagine components have an interface (the Container). > All ofbiz plugins/modules implement this so there should not be a dependency > on implementations. > Perhaps this is a good point to start - separating the container and > depending on it in other modules. > > start will start ofbiz and load modules list from xml + look them up on the > classpath. > > WDYT? How would the list above change with a container API module? About dependency between base and start. Today, Start is packaged in `org.apache.ofbiz.base`, it seems to have been designed to be the only alternative for OFBiz server launch (no other implementation possible). Indeed, this component is the one that stock the launch information (portoffset etc.). To make it happen, there have to be defined interfaces from which actual codebase would be one implementation. Is that what you envision, if so this could be a good first example of circular dependency removal. Other example, regarding common component, that contains common elements applicable to any other component like Unit of measure, lookups, emails. For those, the services can be based upon screen to generate the desired results inducing a dependency toward the widget component. Moreover, lots of display information are propagated by Visual theme, (during login, emails, freemarker engine preparation). We might need to integrate all of these into base component using interface OR split into the good/new component OR decide that OFBiz nature is to live with widgets in its core. > > Another helpful thing is to establish the boundaries of each project. > What should each module do and what it should NOT do? * service : contains all soa configuration and engine to manage services * entity : contains all database / entity management * common : contains functional widget, data, services that can be used by all other components * base : contains technical low level code for all OFBiz components * start : launching, stopping OFBiz server instance, managing start configuration * security : as is named, tools to manage user security * webapp : engine to manage exchange between servlet and controller definition * entityext : container that extend the entity engine on some element not vital for OFBiz to run like entity sync, cache distribution, ... * datafile: tools to create/read big data file base on xml definition * testtools: integration test engine * catalina: container for embedded tomcat * widget: screen rendering based on xml definition * webtools: web interface to analyse and manage different OFBiz engines Thanks Eugen, Nicolas and Gil signature.asc Description: PGP signature
Re: Next rather than old demo
Hello Jacques, I agree it's better to show the present and future. Thanks, Gil On Mon, Sep 06, 2021 at 11:47:18AM +0300, Eugen Stan wrote: > On 03.09.2021 20:00, Jacques Le Roux wrote: > > Hi, > > > > We have an old demo. It's the previous stable. I think we should rather > > think about the future than the past. > > > > So I propose to change and replace the old demo by a next demo. It would > > be the next release to be done. For instance at the moment old is R16 > > and next would be R18, etc. > > > > I have already used the same for the documentation: > > https://ci.apache.org/projects/ofbiz/site/ > > > > What do you think? > > > > TIA > > > > Jacques > > > > I think it's a good idea. > I imagine people who care about the old have already an instance running and > can deploy it themselves. > Stable and next would be great. > > Regards, > -- > Eugen Stan > +40720 898 747 / netdava.com signature.asc Description: PGP signature
Re: [VOTE] Apache OFBiz 17.12.08
+1 Checksum, signature and tests are OK Thanks, Gil On Mon, Aug 02, 2021 at 12:24:13PM +0200, Jacques Le Roux wrote: > +1 > > Back and front ends OK > > Checksums OK > > $ ./verify-ofbiz-release.sh apache-ofbiz-17.12.08.zip > sha check of file: apache-ofbiz-17.12.08.zip > Using sha file: apache-ofbiz-17.12.08.zip.sha512 > apache-ofbiz-17.12.08.zip: 624E1793 ED05C3F7 39F28D57 16A1BED8 D79A7787 > 33D047D1 537F07B2 AC05EA2D 425175F3 D8304D04 0B1B7CA1 33651100 14F331DA > A7140EC0 D4C18AB1 2496E0E4 > apache-ofbiz-17.12.08.zip: 624E1793 ED05C3F7 39F28D57 16A1BED8 D79A7787 > 33D047D1 537F07B2 AC05EA2D 425175F3 D8304D04 0B1B7CA1 33651100 14F331DA > A7140EC0 D4C18AB1 2496E0E4 > sha checksum OK > > GPG verification output > gpg: Signature made Mon Aug 2 10:01:25 2021 > gpg: using RSA key 7A580908847AF9E0 > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) > " > > Jacques > > Le 02/08/2021 à 11:22, Jacopo Cappellato a écrit : > > This is the vote thread to release a new bug fix release for the > > release17.12 branch. This new release, "Apache OFBiz 17.12.08" will > > supersede the previous release from the same branch. > > > > The release files can be downloaded from here: > > https://dist.apache.org/repos/dist/dev/ofbiz/ > > and are: > > * apache-ofbiz-17.12.08.zip > > * KEYS: text file with keys > > * apache-ofbiz-17.12.08.zip.asc: the detached signature file > > * apache-ofbiz-17.12.08.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 17.12.08 > > [ -1] do not release > > > > This vote will be open for 5 days. > > > > For more details about this process please refer to > > http://www.apache.org/foundation/voting.html > > > > Best Regards, > > > > Jacopo > signature.asc Description: PGP signature
Re: I'm working on an OFBiz helm chart for kubernetes
Hello Eugen, and thanks Pierre for the reminder :) I just wanted to mention there was a previous effort to implement environment variable configuration [1]. This has not yet be pushed into trunk, but is used by our customer projects. You could check the patch and test if it helps you ease the configuration process. Regards, Gil [1] https://issues.apache.org/jira/browse/OFBIZ-9498 On Thu, Jul 01, 2021 at 10:57:22AM +0200, Pierre Smits wrote: > Hi Ioan, > > My apologies for the late reaction. > > IMO we can forget about the Derby route for this. Derby is not production > grade, and often adopters/implementers already have their preferred RDBMS > for production in play or decided upon. Configuration of such is the > entityengine.xml file, and deployment of such for the various > environments/instances like UAT or PROD can easily managed and deployed via > VCS. > > Best regards, > Pierre Smits > > > On Sun, May 9, 2021 at 9:13 PM Eugen Stan wrote: > > > > > > > Hello, > > > > NOTE: I previously sent this email from an un-subscribed email address, > > please ignore that one. > > > > I'm working on a Helm chart for OFBiz > > https://github.com/ieugen/charts/tree/main/ofbiz . > > > > The goal is to have OFBiz running in Kubernetes. > > > > Right now it's a rough start: it starts OFBiz with Derby and that's > > about it. > > > > I'll keep pushing updates as soon as I have them. > > > > I'm interested in your feedback. > > If you plan on testing it and using it let me know. > > I do accept and encourage collaboration. > > > > If this is interesting I might push it upstream but it uses the binary > > build of OFBiz in Docker. > > > > > > I'm using docker images built from trunk on jdk-11. > > There are amd64 and arm64 (Raspberry PI4) images. > > > > Some issues that need solving are the many configuration files that > > OFBiz has. > > > > This details creates a lot of configuration when deploying in Docker / > > Kubernetes as they need to be mounted in a volume with many entries or > > multiple volumes. > > > > There are many potential solutions to this but it boils down to: > > * It would be nice to load max 1-2 or 3 configuration file with multiple > > sections instead of the currently many configs split over the code base. > > * It would be nice to support configuration (overwrite) via ENV vars for > > some things like DB connection. > > > > > > Regards. > > Eugen > > signature.asc Description: PGP signature
Re: Introduce a "Good First Issue" Jira Label
Hello, Good idea, To add some more about GoodForNewContributors, it seems well used in GitLab platform : https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=good+for+new+contributors So sticking with it seems nice to me. Thanks Le 07/05/2021 à 15:53, Aditya Sharma a écrit : Hi team, Good First Issue label can be used to identify any issue to be a good fit for a new contributor. These issues can be a great way to get started with a project. Then label is widely used by projects on GitHub[2] and quite useful. I propose to introduce a "Good First Issue" like a label to avail more contributions from new people. I noticed there is already a label for GoodForNewContributors[2] used by some projects. We can use the same or have one created as "Good First Issue" as per the conventions all over the world. WDYAT? 1. https://github.com/topics/good-first-issue 2. https://issues.apache.org/jira/browse/REEF-21?jql=labels%20%3D%20GoodForNewContributors Thanks and Regards, Aditya Sharma
Re: [VOTE] [RELEASE] Apache OFBiz 17.12.07
Hello, +1 Tests are OK, basic usage OK, SHA and signature OK Regards, Gil Le 13/04/2021 à 10:39, Jacopo Cappellato a écrit : This is the vote thread to release a new bug fix release for the release17.12 branch. This new release, "Apache OFBiz 17.12.07" will supersede 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-17.12.07.zip * KEYS: text file with keys * apache-ofbiz-17.12.07.zip.asc: the detached signature file * apache-ofbiz-17.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 17.12.07 [ -1] do not release This vote will be open for 5 days. For more details about this process please read http://www.apache.org/foundation/voting.html
Re: Releasing 17.12.05, 18.12.01 and freezing R20
+1 for Michael ! Cheers On Mon, Dec 21, 2020 at 02:57:25PM +0100, Michael Brohl wrote: > +1 for the initial proposal > > with an additional idea: maybe better skip r20 and make a r21 right at the > beginning of the year with the chance to release also in 21. > > This would allow us to catch up and have a more up-to-date release cycle. It > seems a bit outdated to read that r18 is released in 2021... > > What do you think? > > Also +1 for 3 years support of r17 and 5 years support starting with r18. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 21.12.20 um 10:54 schrieb Jacques Le Roux: > > Hi Deepak, > > > > The reason I propose that is because it's more and more difficult to > > backport to R17, when for R18 it's still OK. Also 3 years seems good > > enough for me. > > > > Of course if people think 5 years would be better then the backporting > > question should be discussed... > > > > We could revise that later, because there was much change between R17 an > > trunk and there are less and less now. So we could support R18 for 5 > > years > > > > Jacques > > > > Le 21/12/2020 à 10:38, Deepak Dixit a écrit : > > > +1 > > > > > > I have a question regarding the following point, rest looks good to me. > > > > > > What is the minimum supported year for a release? > > > Do we have any policy regarding this? > > > > > > We should support a release for at least 5 year. > > > > > > Thoughts? > > > > > > Thanks & Regards > > > -- > > > Deepak Dixit > > > ofbiz.apache.org > > > > > > > > > On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato < > > > jacopo.cappell...@gmail.com> wrote: > > > signature.asc Description: PGP signature
Chapter 3 : promoting decorator
Hello devs, This mail introduce the last Chapter of our story that describe in which context we created some new decorators. First, we want to recall the common-theme effort objectives : The common-theme component is the default theme that define every screens that are available for theme surcharge, without technology information (css/html, vuejs or something like that). Every theme is based onto this common-theme that structure the application. Any theme can empower this structure its way, using it’s one technology. The idea is simple, isolating screen definition from technology syntax, let the technology implementation to the theme. Xml Screen and form definition must only be description of the structure. The “how it is render” is defined by default by the common-theme, and might be overloaded by a chosen theme. From these objectives arise the need to list structural descriptive decorator that exists or are added by our effort : The *FindScreenDecorator* : is the existing search screen decorator in OFBiz, it is composed in three sections : * A menu (party creation for instance : menu-bar) * Search criteria (search-option) * Results (search-results) The new *DetailsScreenDecorator* : is a new decorator to show a sum up of an object and its related data. Composed in five sections : * A menu (menu-bar) * A tab menu : to give access to related data into details section (tab-bar) * A summary that display main data of the object (summary) * An action menu (object modification, duplicate or specific actions : actions) * The detail : area that will display related data (details) This structure, in addition to give the display control to the theme, offer the developer not to think about the area to use when he wants to display more data concerning the object. Moreover, when performing actions, the developer do not need to know about the area to refresh, since the screen-engine has been improved to manage it for him. The new *EmbeddedScreenDecorator* : is a new decorator used to inject in an structure page area a specific screen. Its goal is to define what kind of data the screen will have to render to allow the theme to adapt the technology for data rendering. The sections are : * A menu (menu-bar) * An action menu (search filtering, history display…) * single : display of a single form * content : display a content (Image or document) * list : display a list of data Those can be loaded by functional decorator that take charge of basic data retrieval : As an example : *EmbeddedProductCategoryScreenDecorator* That is a specific decorator that implements the *EmbeddedScreenDecorator* and do the data retrieval of productCategory object : This avoid for every embedded screen using productCategory code duplication in data retrieval. The same logic can be applied to *DetailsScreenDecorator*. To see all that in action we are working into a simple demo, in a classical theme and an simple improved theme, we currently are creating a sum-up presentation with illustration and more details like code/video. I hope we will be able to share it with you soon enough. Best Regards signature.asc Description: PGP signature
Re: Chapter two: Rules to dynamize screen
Hello James, No worry i wasn't active due to the situation we are aware of... I plan to get back into the subject in the coming weeks. Regards, Gil On Fri, May 15, 2020 at 04:08:07PM -, James Yong wrote: > Hi Gil, > > Sorry for the late reply. > I agree that button actions should be decoupled from forms. > Shall we continue with Part 3? > > Regards, > James > > On 2020/01/10 17:58:59, Gil Portenseigne wrote: > > Hello ! > > > > In previous thread we focused on the process of how to define a dynamic > > workflow that raises some questions. > > > > Let's go back to our principles: we have to find simple things, limit > > the possibilities (do little but good) and remember that on the > > backoffice it's end-users who are focused on specific tasks. > > > > To make it simple, implement screen dynamism that will generate > > alterations of the dom, to limit side effects, we establish the > > following principles: > > * We can only ask for an update of the area known by the calling > > element. > > > > Knowing that the element of coherence in the screen engine is the > > screen itself, we can refine this rule on the following basis > > * An element triggering a screen update, can only update elements > > present within the screen where it belongs. > > > > Why did we made this choice? We will see it below, but the goal is > > always to make writing easier for the developer by avoiding him to > > wonder what is the value of the area to be refreshed. > > > > If for various reasons we need to update an area outside the screen > > where the call is located, it is better to ask for a global refresh of > > the page. (Always simpler for the developer) > > > > Another point to aim for simplicity, which zone to update? > > We can identify several actions: > > * I'm on an item and I want to see related items data > > * I'm on an item and I want to refresh that item data > > > > The first case is a defined relation, I will refresh this area with > > this screen, area that will be generally determined by the decorator. > > Then, we will talk about the so-called embedded screens: "embedded > > screen". > > > > The second case is about updating oneself following some sort of > > procedure, I have to refresh myself. Nothing is best than "knowing it > > yourself". > > > > It was needed to implement an optimization to facilitate the application > > of these principles. The idea is that in most cases, the developer > > doesn't have to think about which zone he needs to specify to display > > his data. > > > > In order to apply the operation in a homogeneous way, we added new > > structuring decorators in the common-theme with dedicated zone > > identifiers allowing each implementation to exploit the refresh. > > > > For example, for a detail screen of an entity (e.g. product categories), > > we use a "DetailScreenDecorator" decorator. The main refresh area > > "Associated Objects Details" is the main dynamic area of the screen. > > We are going to identify precise areas so that each theme can be used in > > knowledge: > > * breadcrumb: to display how we see the path to an entity > > * summary: to display a quick information on this entity > > * action: different actions available to this entity > > * navigation: links or other element who help user to navigate on > > the entity relation > > * detail: to display a relation > > > > In our searchn once the list of needs is done, we have exploited the > > areas for our theme as follows: > > > > > >+-+ > >| Catalog -> Category (BreadCrumb) | > >| +-+ | > >| | ++| | > >| | | Quick Menu || | > >| | ++| | > >| | | | > >| | Category Summary | | > >| | | | > >| +-+ | > >| | > >| +-+ | > >| |Tab Menu | menu1 | menu2 | menu3 | | > >| |---
Re: Adopting Github Workflow
Hi, On Wed, Mar 11, 2020 at 05:08:47PM +0100, Michael Brohl wrote: > > > > - Adopt Github Pull Request (PR) as the unique channel for code contribution > > -1 > > I don't see a reason why we should not allow patches also. It will make it > easier for people to contribute who are not able (or willing) to run their > own GitHub repository. > > We should encourage people to use PR's but not force it (at least, not > immediately...). Agree encouraging is better, but that will become invalid if it is chosen to use Github as the new way to report issues/improvement contribution. In that case the patch is a more complex way to contribute and discuss contributions. > > > > - Require tickets only for bug reports > > -1 > > Jira tickets for improvements/new features are extremely helpful to have > everything in one place (with the addition to a link to the mailing list > discussion), track the efforts, watch issues etc. > > How would you manage the work then? > Agree that being restrictive is not good. > > > - Replace JIRA with Github issues > > -1 > > Why should we have two different issue management systems when we can have > everything in one place? What advantages do you see for doing so? > > I also would not rely too heavily on GitHub because it is not an official > ASF resource and IMO Jira is a huge knowledge base of the project. > If i understood well the proposal is to *replace* one by another, to avoid the usage of multiple tools (for PR and issues). The problematic is the lost of history and like was said github being external to Apache. But what Jira do offer that github do not ? Is that possible to keep Jira as a legacy bugTracker for history sake ? Is that to much work for us to adapt to this new tool. Do other apache project use github as their bugTracker, and is that an issue ? This has to be analysed. > > > - Use Github API to get the stats for OFBiz monthly reports > > Can you elaborate what you mean/ how you would do it? > I guess that building reports onto number of PR merged/closed, number of commit, listing of github issue by type (those that exists, that matters), etc. Thanks signature.asc Description: PGP signature
Re: Git history problem
+1 IMO i prefer to rebase and check the commit i push in my local repo. Thanks Le 11 mars 2020 16:52:36 GMT+01:00, Mathieu Lirzin a écrit : >>> The simple solution to prevent this is to get into the habit of >>> linearizing history, meaning always rebasing and clean history >before >>> merging into trunk. >> >> I guess the GH merge button option "Rebase and merge" is what we are >> looking to enforce with the request to Infra, right? > >I personnally think we should have *no button* because the committers >should cleanup the commits (reword, squash, ...) before merging to >trunk, but "rebase and merge" is an improvement compared to basic >"merge". -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Groovy Migration : createRequirementFromItemATP
Hello ! While migrating createRequirementFromItemATP, i stumbled upon a comment from David Jones : > NOTE DEJ20090902: this service is not called > anywhere, instead the createATPRequirementsForOrder service (written in > Java) is called; why this is the case I don't know... --> I investigate a bit and find out the commit https://github.com/apache/ofbiz-framework/commit/edc1c0398f77157f590ad99d52e90fc29e251190 That seems to refactor the service. As createRequirementFromItemATP minilang service seems not used in project (outside one integration test), should we not deprecated it in next release (18.12) and remove it in trunk ? WDYT ? Regards, Gil signature.asc Description: PGP signature
Re: buildbot failure in on ofbizTrunkFramework
I introduced a test error with my new test, i'll look into it. Gil On Fri, Mar 06, 2020 at 03:48:10PM +, build...@apache.org wrote: > The Buildbot has detected a new failure on builder ofbizTrunkFramework while > building ofbiz-framework. Full details are available at: > https://ci.apache.org/builders/ofbizTrunkFramework/builds/1311 > > Buildbot URL: https://ci.apache.org/ > > Buildslave for this Build: asf947_ubuntu > > Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' > triggered this build > Build Source Stamp: [branch trunk] 53a8b812607f9987a1063f18062a5318cafe444c > Blamelist: Gil Portenseigne > > BUILD FAILED: failed shell_2 > > Sincerely, > -The Buildbot > > > signature.asc Description: PGP signature
Re: Important Notice on Mailbox Account upgrade for notificati...@ofbiz.apache.org
Nope, same here. signature.asc Description: PGP signature
Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3
+1 On Thu, Feb 27, 2020 at 06:09:34PM +0100, Michael Brohl wrote: > +1 > > ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip > sha check of file: apache-ofbiz-17.12.01.zip > Using sha file: apache-ofbiz-17.12.01.zip.sha512 > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 > 5B8A5358 36208F4A D26DEB40 > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72 > 5B8A5358 36208F4A D26DEB40 > sha checksum OK > > GPG verification output > gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID 847AF9E0 > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) > " [ultimate] > > > ./gradlew loadAll testIntegration > > ... > > :testIntegration > > BUILD SUCCESSFUL > > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 27.02.20 um 10:49 schrieb Jacopo Cappellato: > > This is the vote thread (3nd attempt) to release "Apache OFBiz 17.12.01": > > this is the first release, containing the framework, applications and all > > the plugins from the 17.12 release branches. > > > > The release files can be downloaded from here: > > https://dist.apache.org/repos/dist/dev/ofbiz/ > > > > and are: > > * apache-ofbiz-17.12.01.zip > > * KEYS: text file with keys > > * apache-ofbiz-17.12.01.zip.asc: the detached signature file > > * apache-ofbiz-17.12.01.zip.sha512: checksum file > > > > Please download the zip file, build and test OFBiz and verify the signature > > and checksum (for instructions on testing the signatures see > > http://www.apache.org/info/verification.html). > > > > Vote: > > > > [ +1] release as Apache OFBiz 17.12.01 > > [ -1] do not release > > > > This vote will be open for 5 days. > > For more details about this process please read > > http://www.apache.org/foundation/voting.html > > > signature.asc Description: PGP signature
Re: Impersonation feature, was: Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3
You understand correctly, and moreover a specific permission must be granted to allow the user to impersonate another one. And we even added another security to not allow impersonating a user with more permission than ourselves. When we contributed the feature, it was discussed, and improved regarding the concern that were expressed. And i'm glad that was done this way (improvement through discussion). Gil On Fri, Feb 28, 2020 at 09:01:30AM +0100, Michael Brohl wrote: > *creating a new thread to leave the vote thread untouched* > > > In my understanding from the previous threads about the impersonation > features, it is disabled by default and must be enabled explicitly. > > Using this feature and dealing with the consequences is up to the user then. > So I see no valid concern to have this feature in the codebase. > > Am I missing something? > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > Am 28.02.20 um 08:49 schrieb Gil Portenseigne: > > Hello Pierre, > > > > If you are talking about impersonation feature, that is not in the 17.12 > > branch. > > > > In either way, administrative tools, if we got access to it, allow what > > your are saying. But there is no security issue that grant these > > privilege we are aware of. If you do, please share to the security list. > > > > I'm open to discuss about the "criminal" aspect of the impersonation > > feature, but not on this thread. > > > > Gil > > > > On Fri, Feb 28, 2020 at 02:54:01AM +0100, Pierre Smits wrote: > > > -1 > > > > > > As this release contains software elements that will enable criminal > > > parties to gain access to the implemented OFBiz system of a user (a > > > business organisation) and impersonate valid users with the intent to > > > bring > > > harm to the aforementioned business organisation through transactions > > > registered by the impersonated valid user.. > > > > > > Met vriendelijke groet, > > > > > > Pierre Smits > signature.asc Description: PGP signature
Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3
Hello Pierre, If you are talking about impersonation feature, that is not in the 17.12 branch. In either way, administrative tools, if we got access to it, allow what your are saying. But there is no security issue that grant these privilege we are aware of. If you do, please share to the security list. I'm open to discuss about the "criminal" aspect of the impersonation feature, but not on this thread. Gil On Fri, Feb 28, 2020 at 02:54:01AM +0100, Pierre Smits wrote: > -1 > > As this release contains software elements that will enable criminal > parties to gain access to the implemented OFBiz system of a user (a > business organisation) and impersonate valid users with the intent to bring > harm to the aforementioned business organisation through transactions > registered by the impersonated valid user.. > > Met vriendelijke groet, > > Pierre Smits signature.asc Description: PGP signature
Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #2
A bit late but +1 ! Thanks On Fri, Feb 21, 2020 at 09:24:02AM +0100, Jacopo Cappellato wrote: > This is the vote thread (2nd attempt) to release "Apache OFBiz 17.12.01": > this is the first release, containing the framework, applications and all > the plugins from the 17.12 release branches. > > The release files can be downloaded from here: > https://dist.apache.org/repos/dist/dev/ofbiz/ > > and are: > * apache-ofbiz-17.12.01.zip > * KEYS: text file with keys > * apache-ofbiz-17.12.01.zip.asc: the detached signature file > * apache-ofbiz-17.12.01.zip.sha512: checksum file > > Please download the zip file, build and test OFBiz and verify the signature > and checksum (for instructions on testing the signatures see > http://www.apache.org/info/verification.html). > > Vote: > > [ +1] release as Apache OFBiz 17.12.01 > [ -1] do not release > > This vote will be open for 4 days. > For more details about this process please read > http://www.apache.org/foundation/voting.html signature.asc Description: PGP signature
Re: PMC/Committer resignation
I second Nicolas opinion. I hope that we will evolve and that will allow you to come back in the community in the future. Let me thank you again for your time and kind help. Gil On Sat, Feb 22, 2020 at 02:51:28PM +0100, Nicolas Malin wrote: > It's sad new that you sharing. > > This community lose with your resignation huge skill to move forward. > > Nicolas > > On 22/02/2020 12:35, Mathieu Lirzin wrote: > > Hello, > > > > As of today, I am resigning from my PMC and Committer role. > > > > My initial involvement with OFBiz started in April 2018 as an internship > > in the Néréide team to work on the support RESTful Web APIs. While > > working on that topic I discovered soon enough that this objective would > > take a very long time to achieve because of the huge technical debt that > > has grown over time in the framework internals. Moreover I have > > observed that my colleagues were swamped in the accidental complexity of > > OFBiz (polyglot programming model, cumbersome DSLs, weak typing, ...) > > which is impacting negatively their ability to deliver value to their > > client. > > > > Following those observations, I have spent a huge amount of my time > > (including my weekends) trying to understand, remove, refactor existing > > code to improve OFBiz simplicity which is a pre-requisite for staying > > relevant in the future. > > > > The recent events/discussions lead me to the conclusion that my efforts > > towards the goal of simplifying OFBiz will simply not be able to succeed > > due of the required slow review process and the global lack of > > interest/consensus on that topic. > > > > As a consequence I am unable to continue to participate positively in > > this community anymore. > > > > Kind regards, > > pub RSA 3072/ECF12FF4 2019-12-16 Nicolas Malin > sub RSA 3072/40C9B367 2019-12-16 > signature.asc Description: PGP signature
Re: checkstyle improvements
Inline, > > I'm kinda prefer the "opposite approach", but we need to discuss if this > > improvement is worth the history lost. > > > > In the example you chose, i see no issue capitalizing module, > > resource and other. Updating the rule offer the ability to write a > > constant like : MoDuLe :-). > > So you are suggesting to use the default configuration for constant names > and do a refactoring to make the private constants like module, ressource, > ressource_error follow this configuration (capitalized with underscores)? > This would result lots of modifications. I agree, and those because having a rule that do not protect against strange code, seems not a good fit for Checkstyle. > > I've also seen a configuration option apply the pattern only to > public/protected constants which could be an alternative to reduce the > amount of changes, at least in the first iterations. > > I am open for these alternatives, as long as we can manage to get it into > the codebase smoothly. Yes that is an option. > > > > > > Lots of errors are about line that are 120+ length, missing or uneeded > > space etc. > > > > So that will lead to loads of unrisky modifications. With the usage of > > IDE with checkstyle plugin this can be done nicely. > > I've seen several plugins for Eclipse, any suggestions of a plugin which is > able to use our configuration? I got idea Checkstyle plugin (CheckStyle-Idea) to work with a slight modification of our configuration, moving "LineLength" module under "Checker" module [1] And got it working nicely with the same result as gradle task. But i'm pretty sure that Eclipse ones will do the job. But this modification break the gradle task... so we need to clear that out. [...] > > > > And like Daniel said, it is a good subject for a community week effort. > > +1 > > To make this work out and keep it manageable, we should define some "rules" > how to approach this. > > For example, I'm thinking of > > - a clear separation of checkstyle modifications and other code corrections > which might come to mind when reading the code +1 > > - checkstyle modifications should not change the functionality/program code > in any way. Which means that open API should not be changed either (e.g. > public constants that might be used in third party functionality). If we > want to change them, we should deprecate the old and remove in the upcoming > release branch. So this needs some caution. That's the hard part. > > - formatting only where it is necessary (no reformatting of the whole file) +1 Thanks [1] https://github.com/checkstyle/eclipse-cs/issues/190 signature.asc Description: PGP signature
Re: checkstyle improvements
Hello Pierre, It is interesting but i guess that will be the next step. Thanks On Fri, Feb 14, 2020 at 09:04:49AM +0100, Pierre Smits wrote: > It seems many projects (including those Apache projects in the Hadoop > sphere) use the works of the Apache Yetus (see [1]) project to do > pre-commit checks (including IIUC checkstyle, in an automate way) on patch > files attached to JIRA tickets and Pull Requests in Github against the > latest commit in the branch. This may be helpful to lessen the burden on > the contributor. When configured correctly, the test results appear in the > ticket. Apache HBASE is such a project using Yetus, See as an example [2] > where test results are included through comments of 'Hadoop QA'. > > Maybe we should consider this for our project? > > > [1] https://yetus.apache.org > [2] > https://issues.apache.org/jira/browse/HBASE-14498?jql=project%20%3D%20HBASE%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Best regards, > > Pierre Smits > *Proud* *contributor* (but without privileges)* of* Apache OFBiz > <https://ofbiz.apache.org/>, since 2008 > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > *Apache Directory <https://directory.apache.org>, PMC Member* > Apache Incubator <https://incubator.apache.org>, committer > Apache Steve <https://steve.apache.org>, committer > > > On Thu, Feb 13, 2020 at 9:13 PM Gil Portenseigne < > gil.portensei...@nereide.fr> wrote: > > > Hello Michael, > > > > Adapting checkstyle configuration is less impacting to our codebase but > > make us stay different from the java standard. > > That is the easier path, that will not affect code history. > > > > But about getting nearer from the java standard is IMO a nice to have, to > > make pure java developer feel better discovering OFBiz. > > I'm kinda prefer the "opposite approach", but we need to discuss if this > > improvement is worth the history lost. > > > > In the example you chose, i see no issue capitalizing module, > > resource and other. Updating the rule offer the ability to write a > > constant like : MoDuLe :-). > > > > Lots of errors are about line that are 120+ length, missing or uneeded > > space etc. > > > > So that will lead to loads of unrisky modifications. With the usage of > > IDE with checkstyle plugin this can be done nicely. > > I check that over the near thousand of java file concerned more than 80% > > have less than 50 issue... So we can focus our effort onto the big files > > using a branch to test the idea and ease the issue. > > > > And like Daniel said, it is a good subject for a community week effort. > > > > I'd really like to be able to efficiently use this feature, in one way > > or the other, so thank you for starting this discussion. > > > > Regards, > > > > Gil > > > > > > On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote: > > > Hi *, > > > > > > checkstyle currently reports a huge amount of errors. We currently have > > an > > > error count setup in the configuration to prevent the build from failing > > > because of the present errors. > > > > > > Some thoughts/questions to the community: > > > > > > * should we take an approach to fine-tune the configuration so that it > > > better fits the project style? > > > > > > As an example, constants are currently not allowed to be named "module", > > > "resource" etc. which is a common pattern in our code. Changing from > > > ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$ > > > would allow the common naming. > > > > > > The opposite approach would be to rename those to fit the default > > settings. > > > > > > * should we start an initiative to remove the valid errors like we did > > with > > > the FindBugs initiative some time ago? > > > > > > > > > Thanks for your feedback, > > > > > > Michael Brohl > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > > > > > signature.asc Description: PGP signature
Re: checkstyle improvements
Hello Michael, Adapting checkstyle configuration is less impacting to our codebase but make us stay different from the java standard. That is the easier path, that will not affect code history. But about getting nearer from the java standard is IMO a nice to have, to make pure java developer feel better discovering OFBiz. I'm kinda prefer the "opposite approach", but we need to discuss if this improvement is worth the history lost. In the example you chose, i see no issue capitalizing module, resource and other. Updating the rule offer the ability to write a constant like : MoDuLe :-). Lots of errors are about line that are 120+ length, missing or uneeded space etc. So that will lead to loads of unrisky modifications. With the usage of IDE with checkstyle plugin this can be done nicely. I check that over the near thousand of java file concerned more than 80% have less than 50 issue... So we can focus our effort onto the big files using a branch to test the idea and ease the issue. And like Daniel said, it is a good subject for a community week effort. I'd really like to be able to efficiently use this feature, in one way or the other, so thank you for starting this discussion. Regards, Gil On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote: > Hi *, > > checkstyle currently reports a huge amount of errors. We currently have an > error count setup in the configuration to prevent the build from failing > because of the present errors. > > Some thoughts/questions to the community: > > * should we take an approach to fine-tune the configuration so that it > better fits the project style? > > As an example, constants are currently not allowed to be named "module", > "resource" etc. which is a common pattern in our code. Changing from > ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$ > would allow the common naming. > > The opposite approach would be to rename those to fit the default settings. > > * should we start an initiative to remove the valid errors like we did with > the FindBugs initiative some time ago? > > > Thanks for your feedback, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > signature.asc Description: PGP signature
Re: buildbot failure in on ofbizTrunkFrameworkPlugins
It's an error while cherry picking the bugFix from trunk. I will revert. On Wed, Feb 12, 2020 at 12:10:46PM +0100, Gil Portenseigne wrote: > Yes, i'm on it... > On Wed, Feb 12, 2020 at 11:56:14AM +0100, Jacques Le Roux wrote: > > It's OK, but we have now a compilation in R17: > > https://ci.apache.org/builders/ofbizBranch17Framework > > > > Please Gil have a look > > > > Thanks > > > > Le 12/02/2020 à 09:00, Jacques Le Roux a écrit : > > > Hi Michael, > > > > > > There were no issues before your commit: > > > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins > > > > > > And it was not squashed with another one: > > > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150 > > > > > > I suspect a Buildbot error, I'm testing locally to confirm. I'll also > > > launch the same on Buildbot > > > > > > Jacques > > > > > > Le 12/02/2020 à 07:57, Michael Brohl a écrit : > > > > Hi all, > > > > > > > > the errors reported during the build (test classes not found) do not > > > > seem to have been introduced by my latest change. > > > > > > > > Any ideas where this come from? > > > > > > > > See > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150/steps/shell_5/logs/stdio > > > > > > > > Best regards, > > > > > > > > Michael Brohl > > > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > Am 11.02.20 um 23:51 schrieb build...@apache.org: > > > > > The Buildbot has detected a new failure on builder > > > > > ofbizTrunkFrameworkPlugins while building ofbiz-framework. Full > > > > > details are available at: > > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150 > > > > > > > > > > Buildbot URL: https://ci.apache.org/ > > > > > > > > > > Buildslave for this Build: asf946_ubuntu > > > > > > > > > > Build Reason: downstream > > > > > Build Source Stamp: [branch trunk] > > > > > 3788f6766a01eb476c15d32e6b9d9127061d12f4 > > > > > Blamelist: Michael Brohl > > > > > > > > > > BUILD FAILED: failed shell_5 > > > > > > > > > > Sincerely, > > > > > -The Buildbot > > > > > > > > > > > > > > > > > > > signature.asc Description: PGP signature
Re: buildbot failure in on ofbizTrunkFrameworkPlugins
Yes, i'm on it... On Wed, Feb 12, 2020 at 11:56:14AM +0100, Jacques Le Roux wrote: > It's OK, but we have now a compilation in R17: > https://ci.apache.org/builders/ofbizBranch17Framework > > Please Gil have a look > > Thanks > > Le 12/02/2020 à 09:00, Jacques Le Roux a écrit : > > Hi Michael, > > > > There were no issues before your commit: > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins > > > > And it was not squashed with another one: > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150 > > > > I suspect a Buildbot error, I'm testing locally to confirm. I'll also > > launch the same on Buildbot > > > > Jacques > > > > Le 12/02/2020 à 07:57, Michael Brohl a écrit : > > > Hi all, > > > > > > the errors reported during the build (test classes not found) do not seem > > > to have been introduced by my latest change. > > > > > > Any ideas where this come from? > > > > > > See > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150/steps/shell_5/logs/stdio > > > > > > Best regards, > > > > > > Michael Brohl > > > > > > ecomify GmbH - www.ecomify.de > > > > > > Am 11.02.20 um 23:51 schrieb build...@apache.org: > > > > The Buildbot has detected a new failure on builder > > > > ofbizTrunkFrameworkPlugins while building ofbiz-framework. Full details > > > > are available at: > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150 > > > > > > > > Buildbot URL: https://ci.apache.org/ > > > > > > > > Buildslave for this Build: asf946_ubuntu > > > > > > > > Build Reason: downstream > > > > Build Source Stamp: [branch trunk] > > > > 3788f6766a01eb476c15d32e6b9d9127061d12f4 > > > > Blamelist: Michael Brohl > > > > > > > > BUILD FAILED: failed shell_5 > > > > > > > > Sincerely, > > > > -The Buildbot > > > > > > > > > > > > > > > signature.asc Description: PGP signature
Re: In preparation for the first release from 17.12
Yes, it is a good way to go. Thanks Jacopo On Tue, Feb 11, 2020 at 03:38:46PM +0100, Jacopo Cappellato wrote: > So far it seems that we are in favor of releasing the full version > (framework + plugins) named "Apache OFBiz 17.12.01" and then also the > version without the plugins. > If this is the direction we will take, would it be ok if we first focus and > release the full version "Apache OFBiz 17.12.01" (framework + plugins) and > we postpone the preparation/vote for the framework only version? In this > way we could all focus on one release and could publish it soon (vote > starting this week or the next) and make sure that we do it right; once it > will be published and once we will have all the details documented in our > download page we could focus on the preparation for the new sections and > explanations for the framework only version so that our users don't get > confused. > > Jacopo > > > On Sat, Feb 8, 2020 at 11:04 AM Jacopo Cappellato < > jacopo.cappell...@gmail.com> wrote: > > > Hi all, > > > > based on various threads in this list, the time we will prepare the first > > release from the 17.12 branch is getting close and, since this is the first > > one in which the plugins are separated from the framework, there are a > > few decisions to take. > > > > Should we release two products or just one as in the past? > > Two products mean: > > "Apache OFBiz Framework 17.12.01" > > and > > "Apache OFBiz Plugins 17.12.01" > > One product mean" > > "Apache OFBiz 17.12.01" (framework + plugins) > > > > Alternatively, we could publish the two products at different times; first > > publish "Apache OFBiz Framework 17.12.01" and then later in the year > > publish "Apache OFBiz Plugins 17.12.01"; if this is going to happen then we > > could have for example multiple releases of the Plugins based on the same > > release of the framework. > > > > One other option is to release independently each plugin (or the ones that > > we consider stable enough) rather than all the plugins in one file. > > > > Thanks, > > > > Jacopo > > > > signature.asc Description: PGP signature
Re: In preparation for the first release from 17.12
+1 Regards, Gil On Mon, Feb 10, 2020 at 05:02:18PM +0100, Nicolas Malin wrote: > Hi, > > I most in favor to propose two products like : > > "Apache OFBiz Framework 17.12.01" (framework) > and > "Apache OFBiz Full 17.12.01" (framework + plugins) > > For advanced user, they would use the framework only and retrieve wanted > plugins. > > For discovery, the full version would be available and recommended. > > I don't think that publish plugins alone or each plugin alone would be > an interest for user > > Nicolas > > On 08/02/2020 11:04, Jacopo Cappellato wrote: > > Hi all, > > > > based on various threads in this list, the time we will prepare the first > > release from the 17.12 branch is getting close and, since this is the first > > one in which the plugins are separated from the framework, there are a > > few decisions to take. > > > > Should we release two products or just one as in the past? > > Two products mean: > > "Apache OFBiz Framework 17.12.01" > > and > > "Apache OFBiz Plugins 17.12.01" > > One product mean" > > "Apache OFBiz 17.12.01" (framework + plugins) > > > > Alternatively, we could publish the two products at different times; first > > publish "Apache OFBiz Framework 17.12.01" and then later in the year > > publish "Apache OFBiz Plugins 17.12.01"; if this is going to happen then we > > could have for example multiple releases of the Plugins based on the same > > release of the framework. > > > > One other option is to release independently each plugin (or the ones that > > we consider stable enough) rather than all the plugins in one file. > > > > Thanks, > > > > Jacopo > > pub RSA 3072/ECF12FF4 2019-12-16 Nicolas Malin > sub RSA 3072/40C9B367 2019-12-16 > signature.asc Description: PGP signature
Re: svn commit: r1828233 - /ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
+1 for the fix.
On Tue, Feb 04, 2020 at 12:22:48PM +0100, Michael Brohl wrote:
> During a migration I found that this bugfix was not backported to the 17.12
> release branch.
>
> Should I do it now?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 03.04.18 um 15:06 schrieb mbr...@apache.org:
> > Author: mbrohl
> > Date: Tue Apr 3 13:06:28 2018
> > New Revision: 1828233
> >
> > URL: http://svn.apache.org/viewvc?rev=1828233&view=rev
> > Log:
> > Fixed: Prevent possible NullPointerException.
> >
> > Modified:
> >
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> >
> > Modified:
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> > URL:
> > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java?rev=1828233&r1=1828232&r2=1828233&view=diff
> > ==
> > ---
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> > (original)
> > +++
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> > Tue Apr 3 13:06:28 2018
> > @@ -210,8 +210,11 @@ public class FinAccountServices {
> > Timestamp now = UtilDateTime.nowTimestamp();
> > // now use our values
> > -String finAccountCode =
> > FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(),
> > delegator);
> > -inContext.put("finAccountCode", finAccountCode);
> > +String finAccountCode = null;
> > +if (UtilValidate.isNotEmpty(accountCodeLength)) {
> > +finAccountCode =
> > FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(),
> > delegator);
> > +inContext.put("finAccountCode", finAccountCode);
> > +}
> > // with pin codes, the account code becomes the ID and the
> > pin becomes the code
> > if ("Y".equalsIgnoreCase(requirePinCode)) {
> >
> >
>
signature.asc
Description: PGP signature
Re: Github & notifications
+1 If we do not decide of replacing Jira with Github or another BT, we must keep Jira for contribution tracking. There might be a jira integration in github for that ? Gil On Mon, Feb 03, 2020 at 12:16:11PM +0100, Michael Brohl wrote: > I'm automatically informed about the pull requests, I think that all > committers get those emails. > > IMO, we should make the creation of a Jira mandatory independent of the > contribution channel (patch or PR). That would inform everyone about the > contribution and we have a valid starting point for questions, discussion > etc. regarding the contribution. > > I feel that solely handling this on Github does not increase transparency. > > Regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 03.02.20 um 12:07 schrieb Pierre Smits: > > Hi All, > > > > With the move to Git, we can expect more pull request from Github (see also > > other threads where postings regarding feature branches appeared). > > Unfortunately, currently no notifications appear in a mailing list when > > those PullRequests are initiated. > > > > It seems to me that, if we want to get more engagements (from github > > contributors), aspects such as PullRequests should sent a notification to > > the dev ml. Otherwise these PullRequests remain in limbo, and we risk of > > losing these contributors. > > > > > > Best regards, > > > > Pierre Smits > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > *Apache Directory <https://directory.apache.org>, PMC Member* > > Apache Incubator <https://incubator.apache.org>, committer > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) > > since 2008* > > Apache Steve <https://steve.apache.org>, committer > > > signature.asc Description: PGP signature
Re: [PROPOSAL] Environment variable configuration
Hello, Thanks for proposing your tried and tested configuration solution. The idea of discussion the original proposal about OFBiz configuration with environment variable stayed in my head. In the light of your solution and with our implementation feedback (git branching configuration + env variable), and others contributors feedback, we might elaborate the best to ease configuration management. Thanks and Regards. Gil On Sun, Feb 02, 2020 at 04:40:14PM +0100, Michael Brohl wrote: > Hi everyone, > > the recent discussions reminded me of this thread again. There were a few > people who were curious how we do configuration management and deployment > (now in production for about 10 years). It is working for projects based on > releases 13, 16, 17, 18 and trunk (with either Ant or Gradle). > > Although we have our ways to maintain this as not being part of the official > OFBiz codebase, I still think it is a good approach worth contributing. > > Is this interesting for the community? > > If there is significant interest I would try to re-write the proposal I did > in [1], updated to the newest Gradle mechanism and several aspects for multi > stage projects. > > Cheers, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > [1] > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E > > > Am 17.11.17 um 22:18 schrieb Michael Brohl: > > Hi Jacques, > > > > it takes some effort to make an OFBiz standard compatible patch of the > > mechanism because we have several additions to the configurations. I > > would take the effort if the community wants to adapt it but it's too > > much work for just giving an idea. > > > > I have explained the mechanism in [1]. There it is based on Ant but we > > already use it in projects with Gradle. > > > > We were looking for other solutions during the migration to Gradle but > > haven't found a better approach considering all pros and cons (database > > configuration, environment variables etc.). We use it for years on our > > test- and production environments and it makes the handling of different > > system specific configurations very easy. > > > > We are thinking about the introduction of an additional configuration > > level so that we have the base configuration (containing all > > properties), a project configuration level and the system specific > > configurations. This helps us to additionally maintain projects using > > different sets of plugins. > > > > I'm happy to explain more if something is unclear. > > > > Regards, > > > > Michael > > > > > > [1] > > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E > > > > > > Am 03.11.17 um 11:39 schrieb Jacques Le Roux: > > > That's quite interesting Michael, > > > > > > Would you share in a Jira? Then we could get to merge all > > > experiences and find a consensu. > > > > > > Jacques > > > > > > > > > Le 03/11/2017 à 10:10, Michael Brohl a écrit : > > > > Just an update triggered by the question from Swapnil [1]: our > > > > configuration mechanism mentioned below is now on Gradle so it > > > > would be compatible with 16.11 and later. > > > > > > > > Regards, > > > > > > > > Michael > > > > > > > > [1] > > > > https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E > > > > > > > > > > > > Am 05.07.17 um 17:56 schrieb Michael Brohl: > > > > > Hi Gil, > > > > > > > > > > we have similar challenges and modified OFBiz to deal with > > > > > it easily. We offered to contribute this long time ago > > > > > (2008) but it was decided against [1]. It was suggested to > > > > > use patches instead but I think it's too complicated to > > > > > manage several patch sets for different environments. > > > > > > > > > > We now use a staged configure mechanism which uses a base > > > > > build file, auto detected machine name and provided > > > > > parameters to decide which configurations should be pulled > > > > > for the environment. It's currently Ant based and therefore > > > > > does not fit into the current build mechanism (on t
Re: Removing “base/config/component-load.xml”
I agree with Jacques, i tried several times to participate in the discussion but i am confused about the situation. About this situation, Michael, we get your point about the process of discuss things before modifying not trivial code and I do agree with that. But there can always be mistakes. I'm pretty sure that Mathieu's intentions are well guided, and reading this last email about the bad process of Mathieu contribution make me feel bad for him. I hope we can get past this, now that it is clear, and work together about the technical aspects, which will make it easier for people to intervene. Thanks and best regards. Gil On Fri, Jan 31, 2020 at 04:47:41PM +0100, Jacques Le Roux wrote: > This is exactly the reason why I would prefer to start a new. Things get > confusing. > > I'd finally prefer a new clean thread with the pro and cons for everybody to > make an opinion which would allow to start a vote, since a consensus can't > be reached > > I hope Mathieu could write the pro... > > If we agree on that one of us can star the new clean thread and we can focus > on the underneath of the problem w/o digressing > > I know it's another effort for you and Mathieu, but I can't see a better way > to avoid drowning less concerned people in details. > > We really need to focus, thanks > > Jacques > > Le 31/01/2020 à 16:11, Michael Brohl a écrit : > > Pleas see my previous email, the discussion thread link is there (citating > > your own statement...) > > > > Thanks, > > > > Michael > > > > > > Am 31.01.20 um 15:34 schrieb Jacques Le Roux: > > > Le 31/01/2020 à 15:04, Michael Brohl a écrit : > > > > Hi Jacques, > > > > > > > > inline... > > > > > > > > > > Maybe better to create a new thread? > > > > > > > > We already have a thread for it, started on 22. August 2019. I > > > > would very much appreciate if experienced users/developers would > > > > join this discussion (which I have missed being on vacation at > > > > the time and, having not much response, did not get my attention > > > > until now). > > > > > > Could you please send a link to this thread or its title? I could not > > > find it easily > > > > > > Thanks > > > > > > Jacques > > > > > signature.asc Description: PGP signature
Re: [VOTE] [RELEASE] Apache OFBiz 16.11.07
+1 Thanks On Fri, Jan 31, 2020 at 12:16:54AM +0530, Deepak Dixit wrote: > +1 > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org > > > On Thu, Jan 30, 2020 at 9:56 PM Nicolas Malin > wrote: > > > +1 > > > > Same result from my local > > > > Nicolas > > > > On 30/01/2020 16:06, Michael Brohl wrote: > > > +1 > > > > > > > > > ~/Projects/apache-ofbiz/check-release-16.11.07 > > > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-16.11.07.zip > > > sha check of file: apache-ofbiz-16.11.07.zip > > > Using sha file: apache-ofbiz-16.11.07.zip.sha512 > > > apache-ofbiz-16.11.07.zip: EF6D32A6 7A2C2776 50FBE2B4 47E43D45 > > > BB503EA5 2C84A604 9CA62AD3 6F180589 1C9C7CC3 F4EE67D2 1393957F > > > E51B9525 0A203A6F D093698E 7B8A9A5B DACC8920 > > > apache-ofbiz-16.11.07.zip: EF6D32A6 7A2C2776 50FBE2B4 47E43D45 > > > BB503EA5 2C84A604 9CA62AD3 6F180589 1C9C7CC3 F4EE67D2 1393957F > > > E51B9525 0A203A6F D093698E 7B8A9A5B DACC8920 > > > sha checksum OK > > > > > > GPG verification output > > > gpg: Signature made Thu Jan 30 12:24:18 2020 CET using RSA key ID > > > 847AF9E0 > > > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) > > > " [ultimate] > > > > > > > > > ~/Projects/apache-ofbiz/check-release-16.11.07/apache-ofbiz-16.11.07 > > > ./gradlew loadDefault testIntegration > > > > > > ... > > > > > > BUILD SUCCESSFUL > > > > > > Total time: 3 mins 45.218 secs > > > > > > > > > Thanks, > > > > > > Michael > > > > > > > > > > > > > > > Michael Brohl > > > Geschäftsführer > > > > > > Fon +49 521 448 157-91 > > > Fax +49 521 448 157-99 > > > Mobil+49 160 3664918 > > > Xing xing.com/profile/Michael_Brohl > > > LinkedIn linkedin.com/in/michaelbrohl > > > > > > Company and Management Headquarters: > > > ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland > > > Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de > > > > > > Court Registration: Amtsgericht Bielefeld HRB 41683 > > > Chief Executive Officer: Martin Becker, Michael Brohl > > > > > > Am 30.01.20 um 15:13 schrieb Jacopo Cappellato: > > >> This is the vote thread to release a new bug fix release for the > > >> release16.11 branch. This new release, "Apache OFBiz 16.11.07" will > > >> supersede all the previous releases from the same branch. > > >> Please consider that this may be the last release in the 16.11 series > > >> and > > >> in the future releases will be published from the newer series only. > > >> > > >> The release files can be downloaded from here: > > >> https://dist.apache.org/repos/dist/dev/ofbiz/ > > >> > > >> and are: > > >> * apache-ofbiz-16.11.07.zip > > >> * KEYS: text file with keys > > >> * apache-ofbiz-16.11.07.zip.asc: the detached signature file > > >> * apache-ofbiz-16.11.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 16.11.07 > > >> [ -1] do not release > > >> > > >> This vote will be open for 5 days. > > >> For more details about this process refer to > > >> http://www.apache.org/foundation/voting.html > > >> > > >> Kind Regards, > > >> > > >> Jacopo > > >> > > > > > signature.asc Description: PGP signature
Re: [DISCUSSION] R16 and R17: email password issue and releases
I wonder if it is bad for the project to have 2 years between two releases, 16 => 18 => 20 WDYT ? Gil On Fri, Jan 24, 2020 at 05:31:14PM +0100, Jacques Le Roux wrote: > Le 24/01/2020 à 15:09, Nicolas Malin a écrit : > > On 24/01/2020 14:57, Jacques Le Roux wrote: > > > > > I must say I'm mostly against because of the surplus of effort > > > necessary to backport to both R17 and R18 > > > > > > About R20, as Pierre Smits mentioned in Slack should we not create a > > > R19 before ;) > > If we follow the years, 2019 is now behind. > > Actually it's not a set in stone rule, we could still create a R19 branch, > why wait one year more, and at least 2 years to publish R20? > > Jacques signature.asc Description: PGP signature
Re: [VOTE] Do not release R17 and directly publish R18 instead.
+1 On Fri, Jan 24, 2020 at 11:27:15AM +0100, Jacques Le Roux wrote: > Hi, > > R16 is now an old distribution and has almost reached its end of support. We > can soon expect a last release but we need to think about the next to be > released package > > Some would prefer to release R17 before releasing R18, some would prefer to > bypass R17 release and directly publish R18 instead. > > Vote: > [ +1] Do not release R17 and directly publish R18 instead. > [ -1] Release R17 before releasing R18 > > We had already 3 months to discuss without reaching a consensus, so this vote > will be only open for a week. > > Note that it's not a formal vote to release R17 or R18, as that is another > process documented at > https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz > > Thank you for your attention > > Jacques > signature.asc Description: PGP signature
Chapter two: Rules to dynamize screen
Hello ! In previous thread we focused on the process of how to define a dynamic workflow that raises some questions. Let's go back to our principles: we have to find simple things, limit the possibilities (do little but good) and remember that on the backoffice it's end-users who are focused on specific tasks. To make it simple, implement screen dynamism that will generate alterations of the dom, to limit side effects, we establish the following principles: * We can only ask for an update of the area known by the calling element. Knowing that the element of coherence in the screen engine is the screen itself, we can refine this rule on the following basis * An element triggering a screen update, can only update elements present within the screen where it belongs. Why did we made this choice? We will see it below, but the goal is always to make writing easier for the developer by avoiding him to wonder what is the value of the area to be refreshed. If for various reasons we need to update an area outside the screen where the call is located, it is better to ask for a global refresh of the page. (Always simpler for the developer) Another point to aim for simplicity, which zone to update? We can identify several actions: * I'm on an item and I want to see related items data * I'm on an item and I want to refresh that item data The first case is a defined relation, I will refresh this area with this screen, area that will be generally determined by the decorator. Then, we will talk about the so-called embedded screens: "embedded screen". The second case is about updating oneself following some sort of procedure, I have to refresh myself. Nothing is best than "knowing it yourself". It was needed to implement an optimization to facilitate the application of these principles. The idea is that in most cases, the developer doesn't have to think about which zone he needs to specify to display his data. In order to apply the operation in a homogeneous way, we added new structuring decorators in the common-theme with dedicated zone identifiers allowing each implementation to exploit the refresh. For example, for a detail screen of an entity (e.g. product categories), we use a "DetailScreenDecorator" decorator. The main refresh area "Associated Objects Details" is the main dynamic area of the screen. We are going to identify precise areas so that each theme can be used in knowledge: * breadcrumb: to display how we see the path to an entity * summary: to display a quick information on this entity * action: different actions available to this entity * navigation: links or other element who help user to navigate on the entity relation * detail: to display a relation In our searchn once the list of needs is done, we have exploited the areas for our theme as follows: +-+ | Catalog -> Category (BreadCrumb) | | +-+ | | | ++| | | | | Quick Menu || | | | ++| | | | | | | | Category Summary | | | | | | | +-+ | | | | +-+ | | |Tab Menu | menu1 | menu2 | menu3 | | | |-| | | || | | | | | | | Associated Objects Details | | | | | | | | | | | | | | | | | | | +-+ | +-+ The decorator will set a variable "detailArea" in the context of this screen, which contains the id of the div to refresh to present a new screen (products of the category for example). The positioning of this type of variable facilitates the constraint on the developer to refresh an area of the screen, if he wants to code the Tab menu in a simplified way. Also we are speaking about technical decorator, because we think that it is necessary to add business decorators implementing those, facilitating the recovery of information from the main object that is processed. But we will discuss this in another mail Chapter 3 : promoting decorator usage Best Regards, Leila, Nicolas and Gil signature.asc Description: PGP signature
Re: [DISCUSSION] Make Back-Office screens dynamic
Hello James, Thanks for the reference we will look into that. Regards, On Fri, Jan 10, 2020 at 03:50:23PM -, James Yong wrote: > Hi Gil, > > I wonder if this library helps for a start: > https://github.com/joshualjohnson/jquery.x > > Regards, > James > signature.asc Description: PGP signature
Re: [DISCUSSION] Make Back-Office screens dynamic
Thanks Gavin for sharing, i have a clearer view now :). Le 17:05 - mardi 17 déc., Gavin Mabie a écrit : > Hi Gil > > I used a type=groovy service to resolve the form location eg. > /* > *@paramater formLocaction (where the form resides in the system) > *@parameter formName (passed as request parameter) > * returns an Ofbiz form entity with all the normal functionalties > associated with ModelForm > * this is returned to the http request as a JSON objecct > */ > ModelForm form = FormFactory.getFormFromLocation(formLocation, formName, > entityModelReader, dispatchContext); > > Angular handles the response through a formField service which reads each > Ofbiz formfields (JSON object) and creates a Angular reactive form from > there. The Angualr formFields Service mirrors the Ofbiz field types etc. > > Regards > > Gavin > > > > > > > > On Tue, Dec 17, 2019 at 4:21 PM Gil Portenseigne < > gil.portensei...@nereide.fr> wrote: > > > Hello Gavin, > > > > Thanks for four feedback, that's very interesting ! > > > > Could you elaborate about the OFBiz forms usage you did in your angular > > implementation ? > > You just used view-map with simple screen/form ? > > > > Cheers ! > > > > Gil > > > > Le 12:26 - mardi 17 déc., Gavin Mabie a écrit : > > > Hi Taher > > > > > > I've been using Angular for custom apps over the past year. This is my > > > approach: > > > > > > 1. Ofbiz deployed as an AppServer: > > > 1.1 Ofbiz controller resolves API request calls; > > > 1.2 Ofbiz Service Engine executes Services; > > > 1.3 Entity Engine for persistence; > > > 1.4 Returns JSON object - including Ofbiz context;; > > > 1.5 Ofbiz Forms used for additional business logic, fields etc; > > > 1.6 Ofbiz Screens not used at all. > > > > > > 2. Angular (On Apache HTTPD or Ionic/Cordova/JQueryMobile or even > > > JAVAFX(haven't tried this, but it's possible)): > > > 2.1 Typescripting types for Ofbiz entities used; > > > 2.2 Angular services for API calls corresponding to controller > > > request-mappings; > > > 2.3 Dynamic Angular Forms - based on Ofbiz Form defs; > > > 2.4 Other static content; > > > > > > 3. Authentication > > > 3.1 With JWT; > > > 3.2 Sessionless & no cookies; > > > 3.3 Ofbiz LoginWorker & Permission Engine for authorization; > > > > > > The big takeaway here is that Ofbiz Screens aren't used at all. Ofbiz > > > Forms are used to set fields, execute services and deal with issues like > > > locale etc. > > > > > > Cheers > > > > > > gavin > > > > > > > > > > > > > > > On Sat, Dec 14, 2019 at 6:52 PM Taher Alkhateeb < > > slidingfilame...@gmail.com> > > > wrote: > > > > > > > Hello Gil, > > > > > > > > Great research on the subject, thank you for sharing. > > > > > > > > I could be wrong here, but at a first glance it seems you want to > > > > essentially create a tag " > > > another screen dynamically upon clicking / activating the URL. If my > > > > understanding is correct, then most likely they way you want to > > > > implement this is probably some web request to the backend which > > > > renders back a partial screen that you insert into the DOM right? > > > > > > > > If what I describe above is close to your idea, then I think the > > > > implementation might be relying on the server to do the work of > > > > painting instead of relying on the browser to do the heavy lifting. > > > > This also only works with one widget, which is the URL widget as > > > > opposed to having a general purpose dynamic behavior in the system > > > > (assuming this is desired). > > > > > > > > However, having a general purpose dynamic behavior means we need a > > > > method to bind variables to values at the front end without consulting > > > > the back-end. This reduces the load on the server and provides a > > > > faster / richer experience to the user. But it would be too painful to > > > > rely on plain javascript or jQuery to achieve such a result which is > > > > the reason why frameworks like React, Vue, and others emerged as > > > > modern SPA frameworks. Adopting an SPA framework would provide dynamic > > > > behavior (everywhere) inste
Re: [DISCUSSION] Make Back-Office screens dynamic
Hello Gavin, Thanks for four feedback, that's very interesting ! Could you elaborate about the OFBiz forms usage you did in your angular implementation ? You just used view-map with simple screen/form ? Cheers ! Gil Le 12:26 - mardi 17 déc., Gavin Mabie a écrit : > Hi Taher > > I've been using Angular for custom apps over the past year. This is my > approach: > > 1. Ofbiz deployed as an AppServer: > 1.1 Ofbiz controller resolves API request calls; > 1.2 Ofbiz Service Engine executes Services; > 1.3 Entity Engine for persistence; > 1.4 Returns JSON object - including Ofbiz context;; > 1.5 Ofbiz Forms used for additional business logic, fields etc; > 1.6 Ofbiz Screens not used at all. > > 2. Angular (On Apache HTTPD or Ionic/Cordova/JQueryMobile or even > JAVAFX(haven't tried this, but it's possible)): > 2.1 Typescripting types for Ofbiz entities used; > 2.2 Angular services for API calls corresponding to controller > request-mappings; > 2.3 Dynamic Angular Forms - based on Ofbiz Form defs; > 2.4 Other static content; > > 3. Authentication > 3.1 With JWT; > 3.2 Sessionless & no cookies; > 3.3 Ofbiz LoginWorker & Permission Engine for authorization; > > The big takeaway here is that Ofbiz Screens aren't used at all. Ofbiz > Forms are used to set fields, execute services and deal with issues like > locale etc. > > Cheers > > gavin > > > > > On Sat, Dec 14, 2019 at 6:52 PM Taher Alkhateeb > wrote: > > > Hello Gil, > > > > Great research on the subject, thank you for sharing. > > > > I could be wrong here, but at a first glance it seems you want to > > essentially create a tag " > another screen dynamically upon clicking / activating the URL. If my > > understanding is correct, then most likely they way you want to > > implement this is probably some web request to the backend which > > renders back a partial screen that you insert into the DOM right? > > > > If what I describe above is close to your idea, then I think the > > implementation might be relying on the server to do the work of > > painting instead of relying on the browser to do the heavy lifting. > > This also only works with one widget, which is the URL widget as > > opposed to having a general purpose dynamic behavior in the system > > (assuming this is desired). > > > > However, having a general purpose dynamic behavior means we need a > > method to bind variables to values at the front end without consulting > > the back-end. This reduces the load on the server and provides a > > faster / richer experience to the user. But it would be too painful to > > rely on plain javascript or jQuery to achieve such a result which is > > the reason why frameworks like React, Vue, and others emerged as > > modern SPA frameworks. Adopting an SPA framework would provide dynamic > > behavior (everywhere) instead of certain widgets, and it can be > > expanded to even include page navigation and whatnot. Of course this > > is more work than what you're suggesting here. but if we continue with > > such small improvements, you might end up having lots of javascript > > (maybe that's already the case) which might increase the difficulty of > > adopting an SPA framework in the future. > > > > So it comes down to this question (which I don't necessarily have an > > answer to): > > > > Do you want an SPA framework now or in the future, or do you want to > > continue with status quo into the future? If you want an SPA > > framework, then we should minimize the usage of custom javascript > > everywhere and adopt a framework that completely replaces all the > > javascript that currently exists for all the widgets. If not, then we > > can proceed with your proposition and any others in the future knowing > > that an overhaul is not needed. > > > > Cheers, > > > > Taher Alkhateeb > > > > On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne > > wrote: > > > > > > Chapter One: How to manage the updating area > > > > > > Hello, > > > > > > After different discussions already listed by Taher [1-9], Leila, > > > Nicolas and me tried another approach. > > > Instead of analyzing how to implement different functionalities offered > > > by modern js framework, we did analyzed how end user use, in general, > > > OFBiz and where we, as an integrator, waste more time to create a > > > screen. > > > > > > To help on this huge task, we set some basic rules : > > > * Work only on scree
Re: [DISCUSSION] Make Back-Office screens dynamic
Hello Taher, The proposition you saw with your first glance is about : * Intent : describing into a link/menu definition, the way that the dynamically rendered form will refresh the screen upon submission success * Implementation : adding a tag that will generate a refreshment event on submission within the screen that is inserted into the DOM by the augmented link (like a success callback). That is one step of the proposal, but yes i think you got it well. We have to make clear that our intent is not to add lot of new widget augmentations to get dynamic screens. This new tag that should have been named "callback-update-area", would complete the already existing " Hello Gil, > > Great research on the subject, thank you for sharing. > > I could be wrong here, but at a first glance it seems you want to > essentially create a tag " another screen dynamically upon clicking / activating the URL. If my > understanding is correct, then most likely they way you want to > implement this is probably some web request to the backend which > renders back a partial screen that you insert into the DOM right? > > If what I describe above is close to your idea, then I think the > implementation might be relying on the server to do the work of > painting instead of relying on the browser to do the heavy lifting. > This also only works with one widget, which is the URL widget as > opposed to having a general purpose dynamic behavior in the system > (assuming this is desired). > > However, having a general purpose dynamic behavior means we need a > method to bind variables to values at the front end without consulting > the back-end. This reduces the load on the server and provides a > faster / richer experience to the user. But it would be too painful to > rely on plain javascript or jQuery to achieve such a result which is > the reason why frameworks like React, Vue, and others emerged as > modern SPA frameworks. Adopting an SPA framework would provide dynamic > behavior (everywhere) instead of certain widgets, and it can be > expanded to even include page navigation and whatnot. Of course this > is more work than what you're suggesting here. but if we continue with > such small improvements, you might end up having lots of javascript > (maybe that's already the case) which might increase the difficulty of > adopting an SPA framework in the future. > > So it comes down to this question (which I don't necessarily have an answer > to): > > Do you want an SPA framework now or in the future, or do you want to > continue with status quo into the future? If you want an SPA > framework, then we should minimize the usage of custom javascript > everywhere and adopt a framework that completely replaces all the > javascript that currently exists for all the widgets. If not, then we > can proceed with your proposition and any others in the future knowing > that an overhaul is not needed. > > Cheers, > > Taher Alkhateeb > > On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne > wrote: > > > > Chapter One: How to manage the updating area > > > > Hello, > > > > After different discussions already listed by Taher [1-9], Leila, > > Nicolas and me tried another approach. > > Instead of analyzing how to implement different functionalities offered > > by modern js framework, we did analyzed how end user use, in general, > > OFBiz and where we, as an integrator, waste more time to create a > > screen. > > > > To help on this huge task, we set some basic rules : > > * Work only on screens supported by the theme, defined mainly in xml > > * This concerns only screens used for back-office applications, > > oriented to manage data > > * A developer does not have to know all of js language (or other) > > but can concentrate on the process/view with the end user to > > manage a data > > > > > > After a first brainstorm, we have identified three major cases : > > 1. Navigation and data display > > 2. View event result (data modification, calculation service, ...) > > 3. Update an area to refresh data (after data modification) > > > > Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff > > will be simple to add), we concentrate our attention on case 3. > > > > To update an area, we follow this pattern > > > > 1. We start from a context that display different information > > > > 2. That context display a submit form, use a link or another > > mechanism to call an OFBiz event > > > > 3. After receiving the event return, we refresh the desired area > >
[DISCUSSION] Make Back-Office screens dynamic
Chapter One: How to manage the updating area Hello, After different discussions already listed by Taher [1-9], Leila, Nicolas and me tried another approach. Instead of analyzing how to implement different functionalities offered by modern js framework, we did analyzed how end user use, in general, OFBiz and where we, as an integrator, waste more time to create a screen. To help on this huge task, we set some basic rules : * Work only on screens supported by the theme, defined mainly in xml * This concerns only screens used for back-office applications, oriented to manage data * A developer does not have to know all of js language (or other) but can concentrate on the process/view with the end user to manage a data After a first brainstorm, we have identified three major cases : 1. Navigation and data display 2. View event result (data modification, calculation service, ...) 3. Update an area to refresh data (after data modification) Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff will be simple to add), we concentrate our attention on case 3. To update an area, we follow this pattern 1. We start from a context that display different information 2. That context display a submit form, use a link or another mechanism to call an OFBiz event 3. After receiving the event return, we refresh the desired area with parameters that can come from origin context or from event return. Currently with the screen widget, we can use within a form the element ``. The problem with this use, is that your form needs to know the origin context, to identify what are the areas to update and what are the target to use for the refresh. So your form needs to know where it comes from, what information need to be updated in OFBiz and what will be updated after. This increases complexity for the developer in the way that current form implementation manages : * the data and target to communicate with the server * the behaviour (refreshment) to apply when receiving server response. Example : ... If you want to reuse the same form, you need to create another screen with a new form to redefine the on-event-update-area (for instance create a PartyRole). We change the thinking, because since it is the starting context that better knows itself, it's the starting context that will realize the updating operation. The starting context is the screen/menu that call this form. In general a form is contained in a screen (classic) that is called through a link. So we move the idea on this link : And the form : ... With this logic you can define a new usage of createPartyRole without redefining a form just : After some use we identified as pro and con feedback : * updating form is reusable and contains only code related to the form action * link being in origin context, the developer knows where he is and where he wants to go * Menu oriented management offers a quick vision on how the screen will works * update-area seems to be a too technical name * we always have to manage area to update manually * too many areas to update become a headache and not only for the developer We did not explain how we have done it, to try to focus the discussion on the principles. It would be a pleasure to have some criticism of this approach, and we would try, in a second chapter to introduce other concepts that appeared after the screens were made more dynamic and others to lowers the identified cons. Thanks, The Néréide Team [1] https://s.apache.org/rf94 [2] https://s.apache.org/g5zr [3] https://s.apache.org/XpBO [4] https://s.apache.org/YIL1 [5] https://s.apache.org/836D [6] https://s.apache.org/DhyB [7] https://s.apache.org/Lv9E [8] https://s.apache.org/zKIo [9] https://s.apache.org/D6jx
Re: Github PRs and Jira
Hello, > > > I guess that using existent Github should be ok for official pull > > request, if not, it's always ok to have and attached patch or > > other gitlab reference. > > You mean "Github reference" I guess ? > For this one a really mean gitlab reference like the nereide public gitlab project we already shared (one or two time) in the past :). Gil
Re: Github PRs and Jira
+1 to use gitlab features to work around code, that will help collaboration. I don't know if there is an Apache alternative to get the features without Microsoft. But having two official tools to get contribution is not desired. I guess that using existent Github should be ok for official pull request, if not, it's always ok to have and attached patch or other gitlab reference. Gil Le 11:55 - mardi 03 déc., Jacques Le Roux a écrit : > Le 03/12/2019 à 08:21, Jacopo Cappellato a écrit : > > Now that we have migrated to Git, in my opinion we should really consider > > to adopt the workflow based on PR as our primary method for accepting > > contributions. I understand that it is a relevant change for the community, > > but I also see many advantages and a more natural (for Git) workflow for > > contributors and committers. Contributors would fork from the official repo > > and would submit pull requests that the committers would merge into the > > official branches. > > > I tend to agree, it's simple to merge and commit. We will still maybe need > Jiras when discussions are needed, or in all cases to fill the blog monthly > posts? > > I guess using Github (ie Microsoft :D) is not a problem for the community? > > Opinions are welcome > > Jacques >
Audit max-retry failure async job
Subject : Audit max-retry failure async job Hi all, While working for a customer, we need to send data to an external API. For this purpose we did trigger an Async service with a max-retry to 3, to be resilient with external API unavailability. The fact is that, with this implementation, we do not manage max retried services failures. One way to do it, is to not rely on Jobs but use a new external Api call tools (might be based upon communicationEvent...), not my first choice since the implementation is already done. Another idea, more simple, is to implement a new seca trigger where the event could be ‘async-last-failure’, to trigger another service which role can be to alert/log/replay... I did not yet analyse if this is easily feasible. Any ideas ? Best Regards Gil
Re: Change commit message template?
Hello, When we first decided on the current template, i did understood that jira number was at the end of the first line, that was logical in my view. I was mistaken and did not discussed it by then. Setting Jira number at the end of the first line is fine for me. Gil Le 21:16 - dimanche 17 nov., Taher Alkhateeb a écrit : > Hi Jacques, > > I'm not sure what convention over configuration has to do with what > you're saying :) > > Anyway, it makes sense. Most GIT editors consider the first line to be > subject, and third line onward is the body of the message. So perhaps > we can move the (OFBIZ-) to the end of the first line or maybe > make it the last line in the body or something like that. > > > On Sun, Nov 17, 2019 at 7:05 PM Jacques Le Roux > wrote: > > > > Hi, > > > > While working in Eclipse with Git (ie using eGit which is not my favourite > > tool). I found a warning telling me: > > > > "Second line should be empty to separate commit message header from > > body" > > > > It was argued that it's only a convention[1], but don't we prefer > > "convention over configuration"? > > > > I suggest to change our template according to the convention, ie separate > > the title from the issue number or put the number on the same line (split > > sometimes) than the title > > > > [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=475845 > > > > What do you think? > > > > Jacques > >
Re: [ofbiz-framework] 02/02: Fixed: Update the SvnCheckout Gradle task to used Github svn repo (OFBIZ-11276)
Thanks Jacques, i understood it was temporary and tested it, i was just
curious :)
It is strange to see a git url in svnCheckout utility.
Gil
Le 10:47 - vendredi 08 nov., Jacques Le Roux a écrit :
> Hi Gil,
>
> Yes sure, here it is https://s.apache.org/lwptd
>
> I said it's a temporary feature I used. But I begin to wonder now.
>
> Since at the ASF the official Gitbox is tightly coupled with Github, I think
> we also are able to commit changes through this way.
>
> So I wonder if we should rush into splitting the plugins in Git repos when we
> can still use svn as before...
>
> I'll do one simple commit in ecommerce I need to do, to check this assertion.
>
> Jacques
>
> Le 08/11/2019 à 09:42, Gil Portenseigne a écrit :
> > Hello Jacques,
> >
> > Could you provide a reference to the github feature you mentionned ?
> >
> > Thanks
> >
> > Gil
> >
> > Le 19:02 - mercredi 06 nov., jler...@apache.org a écrit :
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > jleroux pushed a commit to branch trunk
> > > in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> > >
> > > commit 4815de7d92cbd6acbcd88c8524f54dc884bd00d4
> > > Author: Jacques Le Roux
> > > AuthorDate: Wed Nov 6 17:26:47 2019 +0100
> > >
> > > Fixed: Update the SvnCheckout Gradle task to used Github svn repo
> > > (OFBIZ-11276)
> > > Relies on a Github specific feature which allows to use and automated
> > > mirrored svn repo.
> > > (cherry picked from commit 0c489aa609d07acdcfe7ff41f167ca2040046c77)
> > > ---
> > > build.gradle | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/build.gradle b/build.gradle
> > > index 3259468..700498d 100644
> > > --- a/build.gradle
> > > +++ b/build.gradle
> > > @@ -884,7 +884,7 @@ task pullPluginSource(group: ofbizPlugin,
> > > description: 'Download and install a p
> > > if (project.hasProperty('pluginId')) {
> > > task pullPluginFromSvn(type: SvnCheckout) {
> > > -svnUrl =
> > > "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/${pluginId}";
> > > +svnUrl =
> > > "https://github.com/apache/ofbiz-plugins/trunk/${pluginId}";
> > > workspaceDir = "${pluginsDir}/${pluginId}"
> > > }
> > > dependsOn pullPluginFromSvn
> > > @@ -901,7 +901,7 @@ task pullAllPluginsSource(group: ofbizPlugin,
> > > doLast { delete "${pluginsDir}" }
> > > }
> > > task pullPluginsFromSvn(type: SvnCheckout, dependsOn:
> > > deleteBeforePulling) {
> > > -svnUrl =
> > > "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk";
> > > +svnUrl = "https://github.com/apache/ofbiz-plugins/trunk";
> > > workspaceDir = "${pluginsDir}"
> > > }
> > > dependsOn pullPluginsFromSvn
> > >
Re: [ofbiz-framework] 02/02: Fixed: Update the SvnCheckout Gradle task to used Github svn repo (OFBIZ-11276)
Hello Jacques,
Could you provide a reference to the github feature you mentionned ?
Thanks
Gil
Le 19:02 - mercredi 06 nov., jler...@apache.org a écrit :
> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
>
> commit 4815de7d92cbd6acbcd88c8524f54dc884bd00d4
> Author: Jacques Le Roux
> AuthorDate: Wed Nov 6 17:26:47 2019 +0100
>
> Fixed: Update the SvnCheckout Gradle task to used Github svn repo
> (OFBIZ-11276)
>
> Relies on a Github specific feature which allows to use and automated
> mirrored svn repo.
>
> (cherry picked from commit 0c489aa609d07acdcfe7ff41f167ca2040046c77)
> ---
> build.gradle | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/build.gradle b/build.gradle
> index 3259468..700498d 100644
> --- a/build.gradle
> +++ b/build.gradle
> @@ -884,7 +884,7 @@ task pullPluginSource(group: ofbizPlugin, description:
> 'Download and install a p
>
> if (project.hasProperty('pluginId')) {
> task pullPluginFromSvn(type: SvnCheckout) {
> -svnUrl =
> "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/${pluginId}";
> +svnUrl =
> "https://github.com/apache/ofbiz-plugins/trunk/${pluginId}";
> workspaceDir = "${pluginsDir}/${pluginId}"
> }
> dependsOn pullPluginFromSvn
> @@ -901,7 +901,7 @@ task pullAllPluginsSource(group: ofbizPlugin,
> doLast { delete "${pluginsDir}" }
> }
> task pullPluginsFromSvn(type: SvnCheckout, dependsOn:
> deleteBeforePulling) {
> -svnUrl = "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk";
> +svnUrl = "https://github.com/apache/ofbiz-plugins/trunk";
> workspaceDir = "${pluginsDir}"
> }
> dependsOn pullPluginsFromSvn
>
Re: Git repo for each ofbiz plugin
Hello Deepak, all, I do not have a strong opinion about separating plugins into independent git repositories but here are my thought : Plugins integration in OFBiz is intended to be used with a maven repository that hosts the plugin releases for the users. See as a reference the ‘OFBiz Plugins tasks’ or README.adoc about ‘OFBiz plugin system’. We did not implemented an official maven repository for plugin releases, so there is no simple way to install a plugin without using VCS. There might be tasks to be done to have an nice answer to how an user can install a sole plugin from a downloaded release archive. Having separated repositories can offer the ability to clone one plugin easily, but at the cost of separating history from other plugins and framework, and increasing maintenance effort. In that case, some scripting could be done, to automate update on all plugins in your repos. Also we might consider using git submodules [1] into framework to ease plugins management, but i'm not familiar enough with that feature. Without maven i tend to lean toward separate repository, but like i said, no strong opinion. By the way, thanks for your work regarding git migration. Regards, Gil [1] https://git-scm.com/docs/git-submodule Le 16:20 - jeudi 07 nov., Deepak Dixit a écrit : > Agree we may some issues, we need to find out and fix if found. > > As per current git repo, How user can only checkout and use ecommerce or bi > or any single component? > > It was possible in with svn, but in git we need separate repository :) > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org > > > On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux > wrote: > > > Le 07/11/2019 à 08:16, Deepak Dixit a écrit : > > >> For instance, some features in applications are dependent on ecommerce > > >> (maybe some other plugins). And a lot of > > >> data used by applications are in ecommerce, and maybe even other > > plugins. > > >> > > > I think we already had an effort to remove plugin dependencies from > > > framework/applications. > > > > > > -- > > > Deepak Dixit > > Sincerely I don't see much efforts put in this issue. And IMO it needs to > > be resolved before thinking about splitting the plugins. I expect some > > issues else... > > > > Jacques > > > >
Re: Upgrading Groovy 2.4.16 → 2.5.8
Hello Mathieu, I've test the upgrade and saw no issue, so +1. Gil Le 18:19 - dimanche 27 oct., Mathieu Lirzin a écrit : > Hello, > > I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable > release on ‘trunk’. > > I did not detect any issue with the upgrade so I intend to commit the > patch in the following days. If you are aware of an issue please jump > in. > > Thanks. > > [1] https://issues.apache.org/jira/browse/OFBIZ-11263 > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [DISCUSSION] R16 and R17: email password issue and releases
Hello, I think that the one year stabilisation period needed for a new branch to be released is not that far for R18 (less than two month), so I suppose that skipping R17 to avoid maintaining two release branches is a good call. Gil Le 13:29 - samedi 28 sept., Jacques Le Roux a écrit : > Hi, > > As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not working" in > R16, and actually nor in R17. > > It has been fixed in trunk and R18 with OFBIZ-4361. As mentioned there, it's > hard to backport to R17 not even speaking about R16! > > I wonder if a case like that would not make R16 deprecated and start to > release R18, skipping R17. > > Of course if people has the time, the nerves and the guts to backport to R17 > and R16 they are welcome > > What do you think? > > Jacques >
Refactoring ServiceSemaphore (OFBIZ-11204)
Hello, In one of our customer project, where we are using multiple OFBiz instances to run backend jobs, in which some are using service semaphore system. While these semaphore jobs are run quite intensively by several OFBiz process, we stumble upon a lot of 'Error' logs that are polluting other production log, in the fact that these are not really error, but a failure trying to insert a lock into ServiceSemaphore table, that leads to another waiting loop. I then proposed a refactoring of the implementation (jira OFBIZ-11204), that works currently fine in our production environment. Since semaphore feature is a quite critical one, some reviews would be appreciated before commiting it in the codebase. Regards, Gil
Re: Avoiding to log Uel stacktraces (was: svn commit: r1867635 - /ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/string/UelFunctions.java)
Hello Mathieu ! Done, thanks for your review, i hope it is more clear. Gil Le 16:23 - vendredi 27 sept., Mathieu Lirzin a écrit : > Hello Gil, > > p...@apache.org writes: > > > Author: pgil > > Date: Fri Sep 27 13:52:43 2019 > > New Revision: 1867635 > > > > URL: http://svn.apache.org/viewvc?rev=1867635&view=rev > > Log: > > Improved: Refactor UelFunctions.java to remove error management via > > Exception > > (OFBIZ-11213) > > > > This refacto was done to avoid logging stackTrace exception, when it is > > possible > > to manage it without exception. > > The "avoid logging stackTrace exception" part of your commit message > gives the impression that the motivation for this rewrite is to hide > programming errors inside Uel and not necessarily to make the > implementation more understandeable. > > Can you give more context regarding this issue of unwanted/unnecessary > logged stacktraces and explain why you choose the solution of silently > hiding the "stacktrace" instead of fixing the code inside the Uel? > > Thanks. > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Default transaction timeout on screen widget
Same feeling here, i just see it as a smell to analyse, to detect bad
design, system failure (disk access...) or regression.
Regards
Gil
Le 20:45 - mardi 17 sept., Scott Gray a écrit :
> Has anyone ever had a good experience with transaction timeouts? I feel
> like they achieve nothing useful in that:
> 1. They don't interrupt any work that is taking too long (they just prevent
> it from being committed)
> 2. By the time the exception is thrown, all the work is already done and
> the result is that it just gets thrown away in exchange for an error
>
> Surely there's a positive side to them, and I've just never seen it?
>
> But Nicolas, in your case I think the solution lies elsewhere. I don't
> think it's ever ok for a screen to take over a minute to load and tie up
> the http connection all that time. Slow pages happen to all of us, but IMO
> the solution always lies in making the screen faster, limiting the amount
> of data that can be processed in a single request or by making the request
> asynchronous.
>
> Regards
> Scott
>
> On Wed, 11 Sep 2019 at 06:57, Nicolas Malin
> wrote:
>
> > Hi all,
> >
> > Since I increase the sensibility of error message [1], we have on
> > different screen that take some time to rendering an error throw due to
> > transaction timeout.
> >
> > By default each screen is rendering with the default timeout (60s) that
> > isn't enough when you have big data compilation or some external service
> > latency.
> >
> > Of course it's possible to analyze each case with purpose to increase
> > the screen velocity or set a transaction-timeout on screen definition,
> > but as first easy step what do you think if we add a default transaction
> > timeout for screen to 10 minutes with possibility to override by
> > properties ?
> >
> > Example:
> >
> > *
> >
> >
> > framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
> > @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
> > // wrap the whole screen rendering in a transaction, should
> > improve performance in querying and such
> > Map parameters =
> > UtilGenerics.cast(context.get("parameters"));
> > boolean beganTransaction = false;
> > -int transactionTimeout = -1;
> > +int transactionTimeout =
> > UtilProperties.getPropertyAsInteger("widget",
> > "widget.transaction.timeout.default", 600);
> > if (parameters != null) {
> > String transactionTimeoutPar =
> > parameters.get("TRANSACTION_TIMEOUT");
> > if (transactionTimeoutPar != null) {
> > @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
> > // If transaction timeout is present, use it to start the
> > transaction
> > // If transaction timeout is set to zero, no transaction
> > is started
> > if (useTransaction) {
> > -if (transactionTimeout < 0) {
> > -beganTransaction = TransactionUtil.begin();
> > -}
> > -if (transactionTimeout > 0) {
> > -beganTransaction =
> > TransactionUtil.begin(transactionTimeout);
> > -}
> > +beganTransaction =
> > TransactionUtil.begin(transactionTimeout);
> > }
> >
> > // render the screen, starting with the top-level section
> >
> > ***
> >
> > Any remarks ?
> >
> > In parallel i will investigate why the error message catch is so sensible.
> >
> > Nicolas
> >
> > [1] http://svn.apache.org/viewvc?view=revision&revision=1856175
> >
> > --
> > logoNrd <https://nereide.fr/>
> > Nicolas Malin
> > The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
> > is providing software for the public good.
> > informat...@nereide.fr
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> > <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
> >
Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly
Hello Jacques,
I also discussed about it with Mathieu and i find it very interesting.
The main advantage I see is, beside compilation, the integration in your
IDE, that was not optimum, and the possibility to re-use methods from
these script migrated to explicit classes.
So +1
Gil
Le 12:28 - lundi 16 sept., Jacques Le Roux a écrit :
> Hi Devs,
>
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I
> discussed with Mathieu and we had some ideas.
>
> Mathieu suggested to move Groovy scripts from /groovyScripts/
> to/src/main/groovy/.
>
> I was initially reluctant because I love to be able to change things on the
> fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
>
> We also know the advantages of compilation. But then I thought: why not have
> best of both Groovy worlds: compile and on the fly.
>
> I tried and it works. So here is the (simple) plan:
>
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like
> that. It will continuously build on any changes in Gradle sourcesets
>
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
>
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
>
> I see no disadvantages, do you? If nobody disagree with this idea, I'll
> create a Jira for that.
>
> Feedback welcome, thanks
>
> Jacques
>
Re: svn commit: r1858243 - in /ofbiz/ofbiz-plugins/trunk: ecommerce/minilang/customer/CustomerEvents.xml example/template/reports/BarCode.fo.ftl
Hello Suraj,
You commited something about maritalStatus id this commit. I guess its
part of another JIRA.
Regards
Le 06:18 - samedi 27 avril, sur...@apache.org a écrit :
> Author: surajk
> Date: Sat Apr 27 06:18:17 2019
> New Revision: 1858243
>
> URL: http://svn.apache.org/viewvc?rev=1858243&view=rev
> Log:
> Improved: Use code128 instead of code39 for barcode generation.
> (OFBIZ-10896)
> Currently, we are using code39 to generate barcodes but there are some
> limitations of code39 as it only able to encrypt letters from A to Z, digits
> from 0 to 9 and an additional set of special characters – “. $ % + – / *”.
> Thanks Pawan Verma for reporting, analysis and providing the patch. Thanks
> everyone else for providing their inputs during discussion on Dev ML.
>
> Modified:
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
>
> Modified:
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml?rev=1858243&r1=1858242&r2=1858243&view=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> Sat Apr 27 06:18:17 2019
> @@ -550,7 +550,7 @@ under the License.
>
>
>
> -
> +
>
>
> type="Long"> property="EcommerceYearsWithEmployeeNotValid"/>
>
> Modified: ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl?rev=1858243&r1=1858242&r2=1858243&view=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl Sat Apr
> 27 06:18:17 2019
> @@ -38,10 +38,10 @@ under the License.
>
>http://barcode4j.krysalis.org/ns";
>message="${exampleId}">
> -
> +
>0.75in
>.375mm
> -
> +
>
>bottom
>Helvetica
>
>
Re: [PROPOSAL] DataModel - Improve Internal Fields injection
A big post for saying that the feature i just wanted to recall about do not fit your need :). I used it in the past for a critical audit, and was happy with it. Le 14:23 - vendredi 26 avril, Pierre Smits a écrit : > Gill, all, > > The entity_audit_log feature also sprung into my mind shortly after I > posted my comment. > [...] > And last but not least: he fourth -1 regarding the > 'enable_audit_log'-feature is that it doesn't appear to be working as > expected. I did a cursory test with an order some moments ago in ofbiz (see > [1]) and it does not capture the old values on the line items. But I may be > misunderstanding the screen/process there. In my experience i got old and new value, date and userLogin. Regards,
Re: [PROPOSAL] DataModel - Improve Internal Fields injection
Hello Pierre, If you have specific need of Auditing, after suspition of malicious users, you can enable entity_audit_log feature on the desired table. At a cost of performance loss. I do not understand why impersonation feature appears here, since it is a administrator specific feature. If an admin is malicious, having those fields cannot prevent him to destroy/modify/create or do whatever with the data. Like you can guess, my opinion, is not to put those fields onto all entity in OFBiz. I agree that security is important, and OFBiz admin must grant the good permission to the trusted users. If you find out that specific entity miss those fields, it can be added case by case. But i do not feel ok into a global feature. Regards Gil Le 11:17 - vendredi 26 avril, Pierre Smits a écrit : > The two fields are extremely useful (even indispensable) regarding auditing > and data analysis. Consider security assessments and fraud > detection/prevention. > > In trunk, only 48 entities have those fields in following breakdown: > Component Model Entities Having UserLogin fields % > datamodel accounting 160 3 1,88% > datamodel content 64 7 10,94% > datamodel humanres 41 1 2,44% > datamodel manufacturing 7 0,00% > datamodel marketing 32 8 25,00% > datamodel order 106 10 9,43% > datamodel party 81 2 2,47% > datamodel product 168 11 6,55% > datamodel facility 38 4 10,53% > datamodel workeffort 40 1 2,50% > In apps 737 47 6,38% > in framework 98 1 1,02% > Total 835 48 5,75% > > That means that for the majority of the entities (more than 90%) our > adopters (using the data models OOTB) have no way of telling who created a > record and who modified it last. And we are talking about entities > regarding invoices, payments, gl transaction entries, orders, quotes, > product definitions, inventory quantities and locations, receipts, > deliveries etc., all which contain business critical data. > > But also, with the recently feature regarding impersonation added to our > code base which allow other users to change records through OFBiz having > those two fields on each entity becomes business critical. > > IMO the OFBiz should have these two fields established on each entity OOTB. > > Because, if we don't have that, our potential adopters while assessing our > product may walk away, and our existing adopter - even after an upgrade to > a more recent or future release without this - will have an extremely hard > time analysing who created and changed records (the what, where and when > questions) when confronted with nefarious (criminal) users. > > Best regards, > > Pierre Smits > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > *Apache Directory <https://directory.apache.org>, PMC Member* > Apache Incubator <https://incubator.apache.org>, committer > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) > since 2008* > Apache Steve <https://steve.apache.org>, committer > > > On Fri, Apr 26, 2019 at 9:00 AM Pritam Kute > wrote: > > > IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to > > every entity is not that useful. Like for example, if we consider the > > "Visit" entity, I am not able to find any advantage of having these fields > > in this entity. But, it should be added to some crucial entities like > > OrderHeader, OrderItem, ProductPrice(which is already there) to track the > > things like who dod the last price updates or order updates. > > > > Kind Regards, > > -- > > Pritam Kute > > > > > > On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > Le 25/04/2019 à 14:17, Suraj Khurana a écrit : > > > > IMO, this is configurable as Jacques pointed, so need to take any > > action. > > > > In fact, I would suggest showing these fields while searching for any > > > data > > > > from entity-engine in webtools, because they are really helpful while > > > > working in a dev environment for debugging. > > > > > > This could be configurable indeed (less need in production for instance > > so > > > default would be false) > > > > > > Jacques > > > > > > > > > > > Just my two cents !!! > > > > > > > > -- > > > > Best Regards, > > > > Suraj Khurana > > > > TECHNICAL CONSULTANT > > > > mobile: +91 9669750002 > > > > email: suraj.khur...@hotwax.co > > > > www.hotwax.co > > > > > > > > > > > >
Re: Send E-Mails
What I understand is that to keep granted right after the migration if our confluence id is différent from our apache id, we must fill in a INFRA Jira to make the switch ? Le 09:23 - mardi 26 mars, Jacques Le Roux a écrit : > Makes sense Pierre, > > Please Gil checks https://issues.apache.org/jira/browse/INFRA-18028 > > HTH > > Jacques > > Le 26/03/2019 à 09:16, Pierre Smits a écrit : > > Hi Gil, > > > > Does this maybe have something to do with recent migration by INFRA to have > > ApacheIds (LDAP)+password being usable as login credentials? I can't edit > > either. > > > > Best regards, > > > > Pierre Smits > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > *Apache Directory <https://directory.apache.org>, PMC Member* > > Apache Incubator <https://incubator.apache.org>, committer > > *Apache OFBiz <https://ofbiz.apache.org>, 10 years a contributor without > > privileges* > > Apache Steve <https://steve.apache.org>, committer > > > > > > On Tue, Mar 26, 2019 at 8:56 AM Gil Portenseigne < > > gil.portensei...@nereide.fr> wrote: > > > > > Hello there, > > > > > > Do somes actions have been taken on documenting the existence of > > > SystemProperty ? > > > > > > I like the idea of migrating documentation into embedded one. > > > > > > I just wanted to add a note into https://s.apache.org/BPJ5 that alert > > > about SystemProperty, but i seem to miss the modification permission... > > > can someone grant me access ? > > > > > > Thanks > > > > > > Gil > > > > > > > > > Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit : > > > > Actually, I think whatever need to be documented is best placed in our > > > > embedded documentation. We should probably consider freezing all new > > > > documentation in any place that is not the embedded documentation and > > > > try > > > > to migrate everything to it. So email setting docs could be placed > > > > somewhere in our user manual. > > > > > > > > On Fri, May 11, 2018, 11:51 AM Jacques Le Roux < > > > jacques.le.r...@les7arts.com> > > > > wrote: > > > > > > > > > Hi Rishi, > > > > > > > > > > > > > > > Le 09/05/2018 ą 11:12, Rishi Solanki a écrit : > > > > > > Community, I think we should mention the SystemProperty where > > > required in > > > > > > Production Setup Guide or may be we can add version of production > > > setup > > > > > > guide which will tells user upto which release this production setup > > > > > guide > > > > > > will work. I know we discuss this kind of effort in past for all the > > > > > > documents and we agree on some point. But this is quicker to manage > > > > > > Production Setup Guide, if we agree then I can do it. > > > > > Yes good idea, a simple information for concerned versions in the > > > current > > > > > Production Setup Guide fits with me > > > > > > > > > > Jacques > > > > > > I'm fine with either change the existing one or maintain the > > > version. But > > > > > > first we should have one which works always with latest. Thanks! > > > > > > > > > > > > > > > > > > Rishi Solanki > > > > > > Sr Manager, Enterprise Software Development > > > > > > HotWax Systems Pvt. Ltd. > > > > > > Direct: +91-9893287847 > > > > > > http://www.hotwaxsystems.com > > > > > > www.hotwax.co > > > > > > > > > > > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de < > > > i...@agentur-m3.de> > > > > > > wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > here is a problem with my e-mail base-configuration. > > > > > > > > > > > > > > I configured email according to the setup guide: > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+ > > > > > > > Production+Setup+Guide#ApacheOFBizTechnicalProduction > > > >
Re: Send E-Mails
Thanks Jacques :) Le 09:21 - mardi 26 mars, Jacques Le Roux a écrit : > Hi Gil, > > Let me check > > Jacques > > Le 26/03/2019 à 08:56, Gil Portenseigne a écrit : > > Hello there, > > > > Do somes actions have been taken on documenting the existence of > > SystemProperty ? > > > > I like the idea of migrating documentation into embedded one. > > > > I just wanted to add a note into https://s.apache.org/BPJ5 that alert > > about SystemProperty, but i seem to miss the modification permission... > > can someone grant me access ? > > > > Thanks > > > > Gil > > > > > > Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit : > > > Actually, I think whatever need to be documented is best placed in our > > > embedded documentation. We should probably consider freezing all new > > > documentation in any place that is not the embedded documentation and try > > > to migrate everything to it. So email setting docs could be placed > > > somewhere in our user manual. > > > > > > On Fri, May 11, 2018, 11:51 AM Jacques Le Roux > > > > > > wrote: > > > > > > > Hi Rishi, > > > > > > > > > > > > Le 09/05/2018 à 11:12, Rishi Solanki a écrit : > > > > > Community, I think we should mention the SystemProperty where > > > > > required in > > > > > Production Setup Guide or may be we can add version of production > > > > > setup > > > > > guide which will tells user upto which release this production setup > > > > guide > > > > > will work. I know we discuss this kind of effort in past for all the > > > > > documents and we agree on some point. But this is quicker to manage > > > > > Production Setup Guide, if we agree then I can do it. > > > > Yes good idea, a simple information for concerned versions in the > > > > current > > > > Production Setup Guide fits with me > > > > > > > > Jacques > > > > > I'm fine with either change the existing one or maintain the version. > > > > > But > > > > > first we should have one which works always with latest. Thanks! > > > > > > > > > > > > > > > Rishi Solanki > > > > > Sr Manager, Enterprise Software Development > > > > > HotWax Systems Pvt. Ltd. > > > > > Direct: +91-9893287847 > > > > > http://www.hotwaxsystems.com > > > > > www.hotwax.co > > > > > > > > > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de > > > > > > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > here is a problem with my e-mail base-configuration. > > > > > > > > > > > > I configured email according to the setup guide: > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+ > > > > > > Production+Setup+Guide#ApacheOFBizTechnicalProduction > > > > > > SetupGuide-EmailServerSettings > > > > > > > > > > > > > > > > > > Unfortunately no email seems to be sent from server > > > > > > (the send email button in partymgr works fine now (thanks to > > > > > > Jacques!), > > > > > > but no email reaches client). No error message, no error in log. > > > > > > > > > > > > Also I tried to register in the ecommerce system and send > > > > > > an "Forgot Your Password" email, but none of the emails were sent. > > > > > > > > > > > > To get more info about the problem, I wrote a groovy script and > > > > > > copied > > > > > > parts of the sendEmail-code from EmailServices.java. > > > > > > The script below surprisingly works fine and sends emails! > > > > > > > > > > > > So I don't understand, why OFBiz itself does not send mails. > > > > > > Is there any further configuration necessary? > > > > > > > > > > > > > > > > > > > > > > > > The script (which sends mails): > > > > > > > > > > > > import
Re: Send E-Mails
Hello there, Do somes actions have been taken on documenting the existence of SystemProperty ? I like the idea of migrating documentation into embedded one. I just wanted to add a note into https://s.apache.org/BPJ5 that alert about SystemProperty, but i seem to miss the modification permission... can someone grant me access ? Thanks Gil Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit : > Actually, I think whatever need to be documented is best placed in our > embedded documentation. We should probably consider freezing all new > documentation in any place that is not the embedded documentation and try > to migrate everything to it. So email setting docs could be placed > somewhere in our user manual. > > On Fri, May 11, 2018, 11:51 AM Jacques Le Roux > wrote: > > > Hi Rishi, > > > > > > Le 09/05/2018 à 11:12, Rishi Solanki a écrit : > > > Community, I think we should mention the SystemProperty where required in > > > Production Setup Guide or may be we can add version of production setup > > > guide which will tells user upto which release this production setup > > guide > > > will work. I know we discuss this kind of effort in past for all the > > > documents and we agree on some point. But this is quicker to manage > > > Production Setup Guide, if we agree then I can do it. > > Yes good idea, a simple information for concerned versions in the current > > Production Setup Guide fits with me > > > > Jacques > > > > > > I'm fine with either change the existing one or maintain the version. But > > > first we should have one which works always with latest. Thanks! > > > > > > > > > Rishi Solanki > > > Sr Manager, Enterprise Software Development > > > HotWax Systems Pvt. Ltd. > > > Direct: +91-9893287847 > > > http://www.hotwaxsystems.com > > > www.hotwax.co > > > > > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de > > > wrote: > > > > > >> Hello, > > >> > > >> here is a problem with my e-mail base-configuration. > > >> > > >> I configured email according to the setup guide: > > >> > > >> > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+ > > >> Production+Setup+Guide#ApacheOFBizTechnicalProduction > > >> SetupGuide-EmailServerSettings > > >> > > >> > > >> Unfortunately no email seems to be sent from server > > >> (the send email button in partymgr works fine now (thanks to Jacques!), > > >> but no email reaches client). No error message, no error in log. > > >> > > >> Also I tried to register in the ecommerce system and send > > >> an "Forgot Your Password" email, but none of the emails were sent. > > >> > > >> To get more info about the problem, I wrote a groovy script and copied > > >> parts of the sendEmail-code from EmailServices.java. > > >> The script below surprisingly works fine and sends emails! > > >> > > >> So I don't understand, why OFBiz itself does not send mails. > > >> Is there any further configuration necessary? > > >> > > >> > > >> > > >> The script (which sends mails): > > >> > > >> import javax.mail.Session; > > >> > > >> import javax.activation.DataHandler; > > >> import javax.activation.DataSource; > > >> import javax.mail.Message; > > >> import javax.mail.MessagingException; > > >> import javax.mail.SendFailedException; > > >> import javax.mail.Session; > > >> import javax.mail.Transport; > > >> import javax.mail.internet.InternetAddress; > > >> import javax.mail.internet.MimeBodyPart; > > >> import javax.mail.internet.MimeMessage; > > >> import javax.mail.internet.MimeMultipart; > > >> import javax.xml.parsers.ParserConfigurationException; > > >> import javax.xml.transform.stream.StreamSource; > > >> > > >> import org.apache.fop.apps.Fop; > > >> import org.apache.fop.apps.MimeConstants; > > >> import org.apache.ofbiz.base.util.Debug; > > >> import org.apache.ofbiz.base.util.GeneralException; > > >> import org.apache.ofbiz.base.util.HttpClient; > > >> import org.apache.ofbiz.base.util.HttpClientException; > > >> import org.apache.ofbiz.base.util.UtilGenerics; > > >> import org.apache.ofbiz.bas
Re: Welcome to Mathieu Lirzin as new committer!
Welcome Mathieu, and Congratulations ! Gil Le 20:15 - mardi 19 févr., Taher Alkhateeb a écrit : > The OFBiz PMC has invited Mathieu Lirzin to become a new committer and > we are happy to announce that he has accepted this role. > > Some of the reasons for inviting Mathieu include: > > - He is invested in the OFBiz project and has delivered substantial > work to the code base. > - He has demonstrated solid technical skills. > - He adopts a professional attitude towards coding and software development. > - He engages thoughtfully with others and likes to work with the community. > > Please join me in welcoming and congratulating Mathieu! > > Cheers, > Taher Alkhateeb
Re: buildbot failure in on ofbizTrunkFrameworkPlugins
Hello, I just checked again with ‘./gradlew cleanAll loadAll testIntegration’, A got build successful... no failure. Gil Le 20:11 - vendredi 28 déc., Jacques Le Roux a écrit : > Hi Gil, > > Are we sure there is not a test issue with this commit? > > Locally I can't reproduce the same but I have also 4 failures, could you > please check on your side? > > Thanks > > Jacques > > Le 28/12/2018 à 15:28, build...@apache.org a écrit : > > The Buildbot has detected a new failure on builder > > ofbizTrunkFrameworkPlugins while building . Full details are available at: > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/625 > > > > Buildbot URL: https://ci.apache.org/ > > > > Buildslave for this Build: silvanus_ubuntu > > > > Build Reason: downstream > > Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1849853 > > Blamelist: pgil > > > > BUILD FAILED: failed shell_4 > > > > Sincerely, > > -The Buildbot > > > > > > > >
OFBIZ-10691 Refactoring ‘EntityCondition’
Hello, There is a very nice contribution from Mathieu Lirzin about refactoring EntityCondition class hierarchy, to make it more legit and understandable. It is well documented and validated against integration test and basic usage This lies in OFBIZ-10691 Jira, if you want to have a look, i will commit it next week. Also Mathieu ask to not squash the patches within the Jira, and i'm particularly in favor of it, since it is not the custom to do it in OFBiz, i wanted to make it clear :). Regards, Gil
Re: [DISCUSSION] Checking debug levels in Java and Groovy files
Hello,
The difference with the documentation and Mathieu's example is the
presence of String concatenation. Here lies the performance improvment.
If there a simple String is used, the if is uneeded :)
Regards
Gil
Le 19:58 - mardi 11 déc., Taher Alkhateeb a écrit :
> The official documentation mentions that performance is hit [1] with metrics.
>
> [1]
> https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams
> On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin
> wrote:
> >
> > He gets exactly the same performance results (1.08× ns/op) with either
> > of the following options:
> >
> >1) Debug.log("...")
> >2) if (Debug.isEnabled()) { Debug.log("...") }
> >3) Debug.log(() -> "...")
> >
Re: svn commit: r1845086 [2/2] - in /ofbiz/ofbiz-framework/trunk/applications: accounting/webapp/accounting/WEB-INF/ content/webapp/content/WEB-INF/ order/webapp/ordermgr/WEB-INF/ party/webapp/partymg
Hello Suraj, Is there a reason to keep empty path for service event ? Regards Gil Le lundi 29 oct. 2018 à 08:14:55 (-), sur...@apache.org a écrit : > Modified: > ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml > URL: > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml?rev=1845086&r1=1845085&r2=1845086&view=diff > == > --- > ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml > (original) > +++ > ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml > Mon Oct 29 08:14:55 2018 > @@ -482,21 +482,21 @@ under the License. > > > > - > + > > > > > > > - > + > > > > > > > - > + > > > > @@ -509,21 +509,21 @@ under the License. > > > > - > + > value="EditWorkEffortGoodStandards"/> > value="EditWorkEffortGoodStandards"/> > > > > > - > + > value="EditWorkEffortGoodStandards"/> > value="EditWorkEffortGoodStandards"/> > > > > > - > + > value="EditWorkEffortGoodStandards"/> > value="EditWorkEffortGoodStandards"/> > > >
