Thanks JInghai!
Le 29/08/2020 à 14:50, Shi Jinghai a écrit :
Hi Jacques,
It’s about a year ago. My IDE is eclipse. I spent about half of a day to make
Lombok work correctly, Getter/Setter, AllArgsConstructor, plugin version
problem and etc.
Does Lombok plugin worth a requirement and a time investment by all OFBiz
developers? My answer is NO.
Kind Regards,
Shi Jinghai
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
发件人: Jacques Le Roux<mailto:jacques.le.r...@les7arts.com>
发送时间: 2020年8月27日 15:10
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: Re: A little bit of Lombok
Thanks Jinghai,
Is that long ago? Do you remember the most important issues you crossed?
Jacques
Le 27/08/2020 à 06:20, Shi Jinghai a écrit :
Just my 2 cents.
-1 for using Lombok plugin in OFBiz.
I had some not good experiences with this plugin in Apereo CAS 5.3.x.
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
发件人: Daniel Watford<mailto:d...@foomoo.co.uk>
发送时间: 2020年7月28日 20:44
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: 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
