OFBIZ-11900: Approach so far for MacroFormRenderer refactoring
Hello, OFBIZ-11900 covers the work-in-progress effort to refactor MacroFormRenderer by extracting code which builds strings to be executed as FTL macros into a separate builder class. This github branch [1] contains the work-in-progress changes for this issue. Please take a look at this branch and highlight any concerns with the approach. This will give me a chance to address concerns or change approach before too much further work is done. Further to simply extracting code from MacroFormRenderer to a separate builder I wanted to avoid the use of strings to represent FTL macro calls. Instead I added an interface called RenderableFtl to represent an element that can be rendered as part of a FreeMarker template. So far the main RenderableFtls in use are RenderableFtlMacroCall and RenderableFtlString. RenderableFtlString can be used to represent a pre-rendered HTML string as used to construct hidden forms by WidgetWorker. RenderableFtlMacroCall is probably the most important of the RenderableFtl classes as it can be used in place of the strings previously built in MacroFormRenderer to capture an FTL macro call, but without the need for the caller to append quoting and whitespace delimiters for each additional macro call parameter. All the RenderableFtl classes know how to render themselves to a String which will be used by FtlWriter to process the string as an FTL element and then write the result to an Appendable. The reason for these changes are to separate the various concerns involved in rendering a form: - RenderableFtl objects are responsible for rendering their data to an FTL compliant string. - FtlWriter is responsible for processing FTL compliant strings as part of an FTL template and writing the results to an Appendable. - RenderableFtlFormElementsBuilder is responsible for creating RenderableFtl objects for various FieldInfo objects, replacing the FTL macro call strings which were previously built in MacroFormRenderer. - MacroFormRenderer is responsible for orchestrating calls to RenderableFtlFormElementsBuilder to create multiple RenderableFtl objects as needed for rendering a field and passing them to FtlWriter. For example, rendering a DisplayEntityField produces RenderableFtl objects representing the displayed field, an associated hyperlink and a tooltip. Separating these concerns makes testing easier: - MacroFormRendererTest can test orchestration of MacroFormRender's calls to RenderableFtlFormElementsBuilder, rather than having to analyse the strings previously written. - Testing of RenderableFtlFormElementsBuilder focuses on the production of correctly configured RenderableFtl elements based on the given FieldInfo objects, rather than testing the eventual string rendered. - The RenderableFtl objects can be tested by examining the FTL strings produced. To support testing of RenderableFtlFormElementsBuilder a number of Hamcrest Matchers have been created to check that RenderableFtlMacroCall objects have expected name and parameter values. Please excuse the long message :) and please let me know if you have any comments or concerns about the approach I have taken. Thanks, Dan. [1] - https://github.com/danwatford/ofbiz-framework/tree/OFBIZ-11900-WIP -- Daniel Watford
Re: Is the HTML renderer still used?
Thanks Daniel! Michael Brohl ecomify GmbH - www.ecomify.de Am 28.07.20 um 17:42 schrieb Daniel Watford: I did search but couldn't find anything using the HTML renderers. OFBIZ-6281 [1] and its related issues lead me to believe that the package should have been removed a while ago, particularly since HtmlScreenRenderer appears to have been removed. Michael, based on your comments I've created OFBIZ-11927 to deprecate the HTML renderers. [1] - https://issues.apache.org/jira/browse/OFBIZ-6281 [2] - https://issues.apache.org/jira/browse/OFBIZ-11927 On Tue, 28 Jul 2020 at 14:17, Michael Brohl wrote: If the package is not used anywhere (havn't checked), we should deprecate and document it for the next release and remove it in the release which comes after the next release. This should give users enough time to change their projects accordingly. Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 28.07.20 um 14:55 schrieb Jacques Le Roux: Hi Daniel, I indeed see only imports of org.apache.ofbiz.widget.renderer.html under framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/html HtmlMenuWrapper, which uses HtmlMenuRenderer, is used in MenuWrapTransform But I don't see any use of MenuWrapTransform OOTB through menuWrap=org.apache.ofbiz.widget.renderer.MenuWrapTransform I'd go with your WidgetWorker changes if they are trivial in the package ;) If the HTML Render package is no longer in use can we remove it? I think it's a good question you asked, it needs more attention. It could be used by (old) custom projects. We can't be dragged down by them eternally... HTH Jacques Le 25/07/2020 à 10:58, Daniel Watford a écrit : Hello, While working on OFBIZ-11907 ( https://github.com/apache/ofbiz-framework/pull/217) I needed to alter the various callers to WidgetWorker's methods for creating URLs, links and hidden forms. For most of the callers I was able to find examples of their use and therefore (manually) check that current behaviour was maintained after the WidgetWorker changes. However I couldn't find any places where HtmlMenuRenderer and HtmlTreeRenderer were used. I've made minimal changes to HtmlMenuRenderer and HtmlTreeRenderer so they can continue to use WidgetWorker, but without concrete examples of usage I am unable to prove they still work. Is the HTML Renderer package (org.apache.ofbiz.widget.renderer.html) still in use or was it replaced by the Macro Renderer package? If HTML Renderer is still used please please point me at the relevant screens in Ofbiz so I can confirm they have not been broken by the WidgetWorker changes. If the HTML Render package is no longer in use can we remove it? Thanks, Dan. smime.p7s Description: S/MIME Cryptographic Signature
Re: Is the HTML renderer still used?
I did search but couldn't find anything using the HTML renderers. OFBIZ-6281 [1] and its related issues lead me to believe that the package should have been removed a while ago, particularly since HtmlScreenRenderer appears to have been removed. Michael, based on your comments I've created OFBIZ-11927 to deprecate the HTML renderers. [1] - https://issues.apache.org/jira/browse/OFBIZ-6281 [2] - https://issues.apache.org/jira/browse/OFBIZ-11927 On Tue, 28 Jul 2020 at 14:17, Michael Brohl wrote: > If the package is not used anywhere (havn't checked), we should > deprecate and document it for the next release and remove it in the > release which comes after the next release. > > This should give users enough time to change their projects accordingly. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 28.07.20 um 14:55 schrieb Jacques Le Roux: > > Hi Daniel, > > > > I indeed see only imports of org.apache.ofbiz.widget.renderer.html under > > framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/html > > > > HtmlMenuWrapper, which uses HtmlMenuRenderer, is used in > > MenuWrapTransform > > But I don't see any use of MenuWrapTransform OOTB through > > > >menuWrap=org.apache.ofbiz.widget.renderer.MenuWrapTransform > > > > I'd go with your WidgetWorker changes if they are trivial in the > > package ;) > > > >> If the HTML Render package is no longer in use can we remove it? > > I think it's a good question you asked, it needs more attention. > > It could be used by (old) custom projects. We can't be dragged down by > > them eternally... > > > > HTH > > > > Jacques > > > > Le 25/07/2020 à 10:58, Daniel Watford a écrit : > >> Hello, > >> > >> While working on OFBIZ-11907 ( > >> https://github.com/apache/ofbiz-framework/pull/217) I needed to alter > >> the > >> various callers to WidgetWorker's methods for creating URLs, links and > >> hidden forms. > >> > >> For most of the callers I was able to find examples of their use and > >> therefore (manually) check that current behaviour was maintained > >> after the > >> WidgetWorker changes. However I couldn't find any places where > >> HtmlMenuRenderer and HtmlTreeRenderer were used. > >> > >> I've made minimal changes to HtmlMenuRenderer and HtmlTreeRenderer so > >> they > >> can continue to use WidgetWorker, but without concrete examples of > >> usage I > >> am unable to prove they still work. > >> > >> Is the HTML Renderer package (org.apache.ofbiz.widget.renderer.html) > >> still > >> in use or was it replaced by the Macro Renderer package? > >> > >> If HTML Renderer is still used please please point me at the relevant > >> screens in Ofbiz so I can confirm they have not been broken by the > >> WidgetWorker changes. > >> > >> If the HTML Render package is no longer in use can we remove it? > >> > >> Thanks, > >> > >> Dan. > >> > > > > -- Daniel Watford
Re: A little bit of Lombok
Hi Michael, I'd encourage tool use to help us produce software wherever possible, particularly those which are common in the java ecosystem and have a low barrier to entry. In my opinion Lombok is common enough that there are many tutorials available to help developers get up to speed, and it only has an effect on code which is explicitly annotated to use its features so won't have an impact on existing software. Please take a look at the 4 minute video on the Lombok home page [1] where they give a very nice demonstration of how lombok helps reduce boilerplate code. They also link to an article [2] from 2010 about using lombok to reduce boilerplate. There are sections on Limitations and Controversy in the article. I raised the memory issue in case it would be a problem for the build infrastructure, but it doesn't have any impact on runtime performance. Lombok helps us reduce boilerplate code. Rather than maintaining such code by hand we use a tool to do it for us instead, allowing us to reason about code in terms of patterns rather than low-level implementation. For example, if I see that a class is annotated with @Value then I know instances of that class are immutable without needing to double check all the fields are final and initialised in the constructor. If I see a class annotated with @Builder then I know the builder pattern has been applied and the author has taken steps to ensure all elements/configuration needed to construct a valid instance of the class are set. The author can do this by overriding the build method of the Builder class if the default lombok code doesn't satisfy their requirements. Applying the (experimental) @UtilityClass annotation to a class will ensure the default constructor is private rather than having to write the constructor explicitly. I think the above advantages outweigh the disadvantages of introducing an additional ofbiz build step (as would be done by the gradle plugin). I did experiment within IntelliJ by removing the IDE plugin. I could still work on code that made use of lombok annotated classes, but the experience was significantly diminished. IntelliJ still uses gradle for compilation, so I didn't have any problems there, but all the IDE support for code assistance was lost for those classes. I would recommend developers install tools relevant to their IDE if working with lombok annotated classes, but it is not a requirement. There will be a learning curve for developers using lombok, but if we start small we will have patterns we can refer new developers to. Also if it was deemed inappropriate for a particular class to make use of lombok annotations then we could implement the relevant code ourselves. [1] - https://projectlombok.org/ [2] - https://objectcomputing.com/resources/publications/sett/january-2010-reducing-boilerplate-code-with-project-lombok On Tue, 28 Jul 2020 at 14:10, Michael Brohl wrote: > Hi Daniel, > > can you explain what the advantages and disadvantages are? > > Is it worth the introduction of an additional framework, more complex > IDE configuration, an additional Gradle plugin and more memory > consumption and why? > > Thanks for clarification, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 28.07.20 um 14:44 schrieb Daniel Watford: > > Hello, > > > > Back in April the possibility of using Lombok for the generation of some > > boilerplate code was mentioned on the mailing list [1]. > > > > As part of work-in-progress on OFBIZ-11900 (refactoring > MacroFormRenderer) > > I have used Lombok on a few small classes. The work-in-progress branch > can > > be found at [2]. > > > > Only a small amount of Lombok has been used so far, meaning it shouldn't > be > > too difficult to remove it if needed. > > > > In build.gradle I have used the FreeFair Gradle Lombok plugin [3] > > referenced by the Lombok Project [4]. > > > > Building with the lombok plugin seemed to use a lot of memory and caused > > gradle to garbage collect and run out of heap regularly. To resolve this > I > > increased the about of memory available to gradle in gradle.properties > > using: > > > > org.gradle.jvmargs=-Xmx2g -XX\:MaxHeapSize\=4g > > > > Tuning this might be important depending on the CI infrastructure used by > > the Ofbiz project. > > > > You will likely need your IDE to apply annotation processing otherwise > you > > might see warning of missing methods. In IntelliJ I use what appears to > be > > the de facto Lombok plugin [5]. > > Guidance is available from the Lombok project for other IDEs [6]. > > > > Lombok @ToString annotations have been applied to RenderableFtlString and > > RenderableFtlNoop. This causes Lombok to insert toString() methods into > the > > classes based on the class names and field values. > > > > The @Value annotation has been applied to > > MacroCallParameterStringValue, MacroCallParameterBooleanValue > > and MacroCallParameterMapValue. This annotation turns those classes into > > immutable-like entities, where
Re: A little bit of Lombok
Hi I think we need to decide how much is the fair usage of lombok. I have used it previously and it does good job of taking care of removing boilerplate code. However, I feel care must also be taken to determine how much we use it because chances are that the code might not work (potentially) if you upgrade the compiler - for example upgrading from Java 8 to 9 or Java 9 to 10 since it adds bytecodes at the compile time. With its heavy usage, it is also likely to affect the build time as well. There are ways to mitigate such issues however [1] but care must be taken. As far as IDEs are concerned, it is fairly easy, be it Eclipse or IntelliJ. WIth Eclipse, you would typically install it as a plug-in and then Eclipse should not complain about compilation issues. I think we need to evaluate all these pros and cons before deciding on its acceptance. I have not used to more than using it for generating getters and setters. [1] - https://stackoverflow.com/questions/15518405/lombok-slowing-down-build-process-in-large-project#:~:text=Lombok%20is%20an%20annotation%20processor,sources%20or%20throw%20compiler%20errors. Best, Girish On Tue, Jul 28, 2020 at 7:12 PM Eugen Stan wrote: > La 28.07.2020 16:10, Michael Brohl a scris: > > Hi Daniel, > > > > can you explain what the advantages and disadvantages are? > > > > Is it worth the introduction of an additional framework, more complex > > IDE configuration, an additional Gradle plugin and more memory > > consumption and why? > > > > Thanks for clarification, > > > > Michael Brohl > > Hi, > > My 2c: > > I think Lombok is great. > I've used it with my previous Java projects to reduce the amount of > boilerplate needed when writing Java code. > > The lombok annotations are only applied during compilation so they don't > change the runtime behavior. > > The cons are an initial quick setup and a very small learning curve. > The pros are less code to write and review and safer equals and hashcode > (they are generated) . > > I would argue that some of the advantages regarding getters and setters > will be diminished once Records are adopted in Java (second preview) > https://openjdk.java.net/projects/jdk/15/ > > I believe this will be done probably in march 2021 and it will be in > time for the next LTS which hopefully it will be JDK 16 in september > 2021 as per > https://www.oracle.com/java/technologies/java-se-support-roadmap.html . > > That being said Lombok has advantages and can be used very easily. > > > I do think Lombok can be set without a plugin since grade has > annotationProcessor configuration > > https://tomgregory.com/annotation-processors-in-gradle-with-the-annotationprocessor-dependency-configuration/ > > > > -- > Eugen Stan > +40720 898 747 / netdava.com >
Re: Welcome Pawan Verma as new PMC member
Many congratulations Pawan!! Thanks. -- Mridul Pathak > On 28-Jul-2020, at 1:21 PM, Jacques Le Roux > wrote: > > The OFBiz PMC has invited Pawan Verma to become member of the committee and > we are glad to announce that he has accepted the nomination. > > On behalf of the OFBiz PMC, welcome on board Pawan! >
Re: A little bit of Lombok
La 28.07.2020 16:10, Michael Brohl a scris: Hi Daniel, can you explain what the advantages and disadvantages are? Is it worth the introduction of an additional framework, more complex IDE configuration, an additional Gradle plugin and more memory consumption and why? Thanks for clarification, Michael Brohl Hi, My 2c: I think Lombok is great. I've used it with my previous Java projects to reduce the amount of boilerplate needed when writing Java code. The lombok annotations are only applied during compilation so they don't change the runtime behavior. The cons are an initial quick setup and a very small learning curve. The pros are less code to write and review and safer equals and hashcode (they are generated) . I would argue that some of the advantages regarding getters and setters will be diminished once Records are adopted in Java (second preview) https://openjdk.java.net/projects/jdk/15/ I believe this will be done probably in march 2021 and it will be in time for the next LTS which hopefully it will be JDK 16 in september 2021 as per https://www.oracle.com/java/technologies/java-se-support-roadmap.html . That being said Lombok has advantages and can be used very easily. I do think Lombok can be set without a plugin since grade has annotationProcessor configuration https://tomgregory.com/annotation-processors-in-gradle-with-the-annotationprocessor-dependency-configuration/ -- Eugen Stan +40720 898 747 / netdava.com
Re: Is the HTML renderer still used?
If the package is not used anywhere (havn't checked), we should deprecate and document it for the next release and remove it in the release which comes after the next release. This should give users enough time to change their projects accordingly. Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 28.07.20 um 14:55 schrieb Jacques Le Roux: Hi Daniel, I indeed see only imports of org.apache.ofbiz.widget.renderer.html under framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/html HtmlMenuWrapper, which uses HtmlMenuRenderer, is used in MenuWrapTransform But I don't see any use of MenuWrapTransform OOTB through menuWrap=org.apache.ofbiz.widget.renderer.MenuWrapTransform I'd go with your WidgetWorker changes if they are trivial in the package ;) If the HTML Render package is no longer in use can we remove it? I think it's a good question you asked, it needs more attention. It could be used by (old) custom projects. We can't be dragged down by them eternally... HTH Jacques Le 25/07/2020 à 10:58, Daniel Watford a écrit : Hello, While working on OFBIZ-11907 ( https://github.com/apache/ofbiz-framework/pull/217) I needed to alter the various callers to WidgetWorker's methods for creating URLs, links and hidden forms. For most of the callers I was able to find examples of their use and therefore (manually) check that current behaviour was maintained after the WidgetWorker changes. However I couldn't find any places where HtmlMenuRenderer and HtmlTreeRenderer were used. I've made minimal changes to HtmlMenuRenderer and HtmlTreeRenderer so they can continue to use WidgetWorker, but without concrete examples of usage I am unable to prove they still work. Is the HTML Renderer package (org.apache.ofbiz.widget.renderer.html) still in use or was it replaced by the Macro Renderer package? If HTML Renderer is still used please please point me at the relevant screens in Ofbiz so I can confirm they have not been broken by the WidgetWorker changes. If the HTML Render package is no longer in use can we remove it? Thanks, Dan. smime.p7s Description: S/MIME Cryptographic Signature
Re: A little bit of Lombok
Hi Daniel, can you explain what the advantages and disadvantages are? Is it worth the introduction of an additional framework, more complex IDE configuration, an additional Gradle plugin and more memory consumption and why? Thanks for clarification, Michael Brohl ecomify GmbH - www.ecomify.de Am 28.07.20 um 14:44 schrieb Daniel Watford: Hello, Back in April the possibility of using Lombok for the generation of some boilerplate code was mentioned on the mailing list [1]. As part of work-in-progress on OFBIZ-11900 (refactoring MacroFormRenderer) I have used Lombok on a few small classes. The work-in-progress branch can be found at [2]. Only a small amount of Lombok has been used so far, meaning it shouldn't be too difficult to remove it if needed. In build.gradle I have used the FreeFair Gradle Lombok plugin [3] referenced by the Lombok Project [4]. Building with the lombok plugin seemed to use a lot of memory and caused gradle to garbage collect and run out of heap regularly. To resolve this I increased the about of memory available to gradle in gradle.properties using: org.gradle.jvmargs=-Xmx2g -XX\:MaxHeapSize\=4g Tuning this might be important depending on the CI infrastructure used by the Ofbiz project. You will likely need your IDE to apply annotation processing otherwise you might see warning of missing methods. In IntelliJ I use what appears to be the de facto Lombok plugin [5]. Guidance is available from the Lombok project for other IDEs [6]. Lombok @ToString annotations have been applied to RenderableFtlString and RenderableFtlNoop. This causes Lombok to insert toString() methods into the classes based on the class names and field values. The @Value annotation has been applied to MacroCallParameterStringValue, MacroCallParameterBooleanValue and MacroCallParameterMapValue. This annotation turns those classes into immutable-like entities, where all fields must be set in the inserted constructor and are available from automatically inserted getters. ToString(), equals and hashCode() methods are also created meaning these classes can be relied upon as map keys if needed. The @Builder annotation has been applied to RenderableFtlMacroCall and RenderableFtlSequence. This annotation does quite a lot so I'd recommend you run delombok (instructions below) to see the code that Lombok inserts for us. To see the sources generated by Lombok we can run DeLombok. At the command line execute: ./gradlew delombok A copy of all sources (not just those with lombok annotations) will be placed under build/delombok. Please take a look at the delomboked sources for the above classes under build/delombok/main/org/apache/ofbiz/widget/renderer/macro/parameter and build/delombok/main/org/apache/ofbiz/widget/renderer/macro/renderable. Please let me know what you think about this usage of Lombok. Thanks, Dan. [1] - http://ofbiz.135035.n4.nabble.com/Default-constructors-in-JAVA-classes-tp4749257p4749258.html [2] - https://github.com/danwatford/ofbiz-framework/tree/OFBIZ-11900-WIP [3] - https://plugins.gradle.org/plugin/io.freefair.lombok [4] - https://projectlombok.org/setup/gradle [5] - https://plugins.jetbrains.com/plugin/6317-lombok/ [6] - https://projectlombok.org/setup/overview smime.p7s Description: S/MIME Cryptographic Signature
Re: Is the HTML renderer still used?
Hi Daniel, I indeed see only imports of org.apache.ofbiz.widget.renderer.html under framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/html HtmlMenuWrapper, which uses HtmlMenuRenderer, is used in MenuWrapTransform But I don't see any use of MenuWrapTransform OOTB through menuWrap=org.apache.ofbiz.widget.renderer.MenuWrapTransform I'd go with your WidgetWorker changes if they are trivial in the package ;) If the HTML Render package is no longer in use can we remove it? I think it's a good question you asked, it needs more attention. It could be used by (old) custom projects. We can't be dragged down by them eternally... HTH Jacques Le 25/07/2020 à 10:58, Daniel Watford a écrit : Hello, While working on OFBIZ-11907 ( https://github.com/apache/ofbiz-framework/pull/217) I needed to alter the various callers to WidgetWorker's methods for creating URLs, links and hidden forms. For most of the callers I was able to find examples of their use and therefore (manually) check that current behaviour was maintained after the WidgetWorker changes. However I couldn't find any places where HtmlMenuRenderer and HtmlTreeRenderer were used. I've made minimal changes to HtmlMenuRenderer and HtmlTreeRenderer so they can continue to use WidgetWorker, but without concrete examples of usage I am unable to prove they still work. Is the HTML Renderer package (org.apache.ofbiz.widget.renderer.html) still in use or was it replaced by the Macro Renderer package? If HTML Renderer is still used please please point me at the relevant screens in Ofbiz so I can confirm they have not been broken by the WidgetWorker changes. If the HTML Render package is no longer in use can we remove it? Thanks, Dan.
A little bit of Lombok
Hello, Back in April the possibility of using Lombok for the generation of some boilerplate code was mentioned on the mailing list [1]. As part of work-in-progress on OFBIZ-11900 (refactoring MacroFormRenderer) I have used Lombok on a few small classes. The work-in-progress branch can be found at [2]. Only a small amount of Lombok has been used so far, meaning it shouldn't be too difficult to remove it if needed. In build.gradle I have used the FreeFair Gradle Lombok plugin [3] referenced by the Lombok Project [4]. Building with the lombok plugin seemed to use a lot of memory and caused gradle to garbage collect and run out of heap regularly. To resolve this I increased the about of memory available to gradle in gradle.properties using: org.gradle.jvmargs=-Xmx2g -XX\:MaxHeapSize\=4g Tuning this might be important depending on the CI infrastructure used by the Ofbiz project. You will likely need your IDE to apply annotation processing otherwise you might see warning of missing methods. In IntelliJ I use what appears to be the de facto Lombok plugin [5]. Guidance is available from the Lombok project for other IDEs [6]. Lombok @ToString annotations have been applied to RenderableFtlString and RenderableFtlNoop. This causes Lombok to insert toString() methods into the classes based on the class names and field values. The @Value annotation has been applied to MacroCallParameterStringValue, MacroCallParameterBooleanValue and MacroCallParameterMapValue. This annotation turns those classes into immutable-like entities, where all fields must be set in the inserted constructor and are available from automatically inserted getters. ToString(), equals and hashCode() methods are also created meaning these classes can be relied upon as map keys if needed. The @Builder annotation has been applied to RenderableFtlMacroCall and RenderableFtlSequence. This annotation does quite a lot so I'd recommend you run delombok (instructions below) to see the code that Lombok inserts for us. To see the sources generated by Lombok we can run DeLombok. At the command line execute: ./gradlew delombok A copy of all sources (not just those with lombok annotations) will be placed under build/delombok. Please take a look at the delomboked sources for the above classes under build/delombok/main/org/apache/ofbiz/widget/renderer/macro/parameter and build/delombok/main/org/apache/ofbiz/widget/renderer/macro/renderable. Please let me know what you think about this usage of Lombok. Thanks, Dan. [1] - http://ofbiz.135035.n4.nabble.com/Default-constructors-in-JAVA-classes-tp4749257p4749258.html [2] - https://github.com/danwatford/ofbiz-framework/tree/OFBIZ-11900-WIP [3] - https://plugins.gradle.org/plugin/io.freefair.lombok [4] - https://projectlombok.org/setup/gradle [5] - https://plugins.jetbrains.com/plugin/6317-lombok/ [6] - https://projectlombok.org/setup/overview -- Daniel Watford
Re: Welcome Pawan Verma as new PMC member
Many congratulations Pawan! Kind regards, -- Ravi Lodhi On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > The OFBiz PMC has invited Pawan Verma to become member of the committee > and we are glad to announce that he has accepted the nomination. > > On behalf of the OFBiz PMC, welcome on board Pawan! > >
Re: Welcome Pawan Verma as new PMC member
Many Many congrats Pawan..!! Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Tue, Jul 28, 2020 at 2:18 PM Pritam Kute wrote: > Congratulations Pawan! > > Kind Regards, > -- > Pritam Kute > > > On Tue, Jul 28, 2020 at 2:16 PM Girish Vasmatkar < > girish.vasmat...@hotwaxsystems.com> wrote: > > > Many congratulations Pawan. > > > > Best, > > Girish > > > > On Tue, Jul 28, 2020 at 2:10 PM Devanshu Vyas > > > wrote: > > > > > Many many Congratulations Pawan!! > > > > > > > > > Thanks & Regards, > > > Devanshu Vyas. > > > > > > > > > On Tue, Jul 28, 2020 at 1:53 PM Aditya Sharma > > > > wrote: > > > > > > > Felicitation Pawan!! > > > > > > > > Thanks and Regards, > > > > Aditya Sharma > > > > > > > > On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < > > > > jacques.le.r...@les7arts.com> wrote: > > > > > > > > > The OFBiz PMC has invited Pawan Verma to become member of the > > committee > > > > > and we are glad to announce that he has accepted the nomination. > > > > > > > > > > On behalf of the OFBiz PMC, welcome on board Pawan! > > > > > > > > > > > > > > > > > > > >
Re: Welcome Pawan Verma as new PMC member
Congratulations Pawan! Kind Regards, -- Pritam Kute On Tue, Jul 28, 2020 at 2:16 PM Girish Vasmatkar < girish.vasmat...@hotwaxsystems.com> wrote: > Many congratulations Pawan. > > Best, > Girish > > On Tue, Jul 28, 2020 at 2:10 PM Devanshu Vyas > wrote: > > > Many many Congratulations Pawan!! > > > > > > Thanks & Regards, > > Devanshu Vyas. > > > > > > On Tue, Jul 28, 2020 at 1:53 PM Aditya Sharma > > wrote: > > > > > Felicitation Pawan!! > > > > > > Thanks and Regards, > > > Aditya Sharma > > > > > > On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < > > > jacques.le.r...@les7arts.com> wrote: > > > > > > > The OFBiz PMC has invited Pawan Verma to become member of the > committee > > > > and we are glad to announce that he has accepted the nomination. > > > > > > > > On behalf of the OFBiz PMC, welcome on board Pawan! > > > > > > > > > > > > > >
Re: Welcome Pawan Verma as new PMC member
Many congratulations Pawan. Best, Girish On Tue, Jul 28, 2020 at 2:10 PM Devanshu Vyas wrote: > Many many Congratulations Pawan!! > > > Thanks & Regards, > Devanshu Vyas. > > > On Tue, Jul 28, 2020 at 1:53 PM Aditya Sharma > wrote: > > > Felicitation Pawan!! > > > > Thanks and Regards, > > Aditya Sharma > > > > On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > The OFBiz PMC has invited Pawan Verma to become member of the committee > > > and we are glad to announce that he has accepted the nomination. > > > > > > On behalf of the OFBiz PMC, welcome on board Pawan! > > > > > > > > >
Re: Welcome Pawan Verma as new PMC member
Many many Congratulations Pawan!! Thanks & Regards, Devanshu Vyas. On Tue, Jul 28, 2020 at 1:53 PM Aditya Sharma wrote: > Felicitation Pawan!! > > Thanks and Regards, > Aditya Sharma > > On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > The OFBiz PMC has invited Pawan Verma to become member of the committee > > and we are glad to announce that he has accepted the nomination. > > > > On behalf of the OFBiz PMC, welcome on board Pawan! > > > > >
Re: Welcome Pawan Verma as new PMC member
Felicitation Pawan!! Thanks and Regards, Aditya Sharma On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > The OFBiz PMC has invited Pawan Verma to become member of the committee > and we are glad to announce that he has accepted the nomination. > > On behalf of the OFBiz PMC, welcome on board Pawan! > >
Re: Welcome Pawan Verma as new PMC member
Many congratulations, Pawan! -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* cell: +91-9893479711 http://www.hotwaxsystems.com On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > The OFBiz PMC has invited Pawan Verma to become member of the committee > and we are glad to announce that he has accepted the nomination. > > On behalf of the OFBiz PMC, welcome on board Pawan! > >
Re: Welcome Pawan Verma as new PMC member
Many congratulations, Pawan ! -- Best Regards, Suraj Khurana Senior Technical Consultant On Tue, Jul 28, 2020 at 1:22 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > The OFBiz PMC has invited Pawan Verma to become member of the committee > and we are glad to announce that he has accepted the nomination. > > On behalf of the OFBiz PMC, welcome on board Pawan! > >
Welcome Pawan Verma as new PMC member
The OFBiz PMC has invited Pawan Verma to become member of the committee and we are glad to announce that he has accepted the nomination. On behalf of the OFBiz PMC, welcome on board Pawan!
