Re: JsLanguageFilesMappingCreator.java

[Suraj Khurana]

Thanks Jacques for taking care of it.

--

Best Regards,
Suraj Khurana
Senior Technical Consultant


On Thu, Aug 27, 2020 at 10:44 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Suraj,
>
> Pushed with slight changes
>
> Jacques
>
> Le 27/08/2020 à 13:37, Jacques Le Roux a écrit :
> > Sure I'll, it's long ago but I still remember the difficulties ;)
> >
> > Jacques
> >
> > Le 27/08/2020 à 12:59, Suraj Khurana a écrit :
> >> Thanks Jacques.
> >>
> >> I have attached a patch at
> https://issues.apache.org/jira/browse/OFBIZ-11926
> >> Could you please review it?
> >>
> >> TIA.
> >>
> >> --
> >> Best Regards,
> >> Suraj Khurana
> >> Senior Technical Consultant
> >>
> >>
> >> On Thu, Aug 27, 2020 at 3:38 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> James,
> >>>
> >>> Seems you are not concerned. Because with OFBIZ-11958 you created
> >>> JsLanguageFilesMappingTransform.java.
> >>> And it's not, and does not need to be, generated by
> >>> JsLanguageFilesMappingCreator::createJsLanguageFileMapping
> >>>
> >>> If you agree you need to put an ASL2 header in it.
> >>> And I'll revert
> >>>
> https://github.com/apache/ofbiz-framework/commit/707acc7d2744c32519aab67e78b8e0e293cb01d6/
> >>>
> >>> TIA
> >>>
> >>> Jacques
> >>>
> >>> Le 27/08/2020 à 11:54, Jacques Le Roux a écrit :
>  Hi James, Suraj,
> 
>  As it's documented inside
> >>> JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by
> the
> >>> createJsLanguageFileMapping service to "create
>  or update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl
> >>> files."
>  This happens when we update the languages used by some JavaScript
> >>> plugins, notably those:
>  "/common/common-theme/webapp/js/jquery/ui/i18n/"
>  "/common/common-theme/webapp/js/jquery/plugins/datejs/"
>  "/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
>  "/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
>  "/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"
> 
>  We then must manually run the createJsLanguageFileMapping service.
> 
>  So we should not modify JsLanguageFilesMapping.java and
> >>> JsLanguageFilesMapping.ftl but modify
>  JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to
> >>> correctly generate them.
>  You both have recently modified JsLanguageFilesMapping.java or/and
> >>> JsLanguageFilesMapping.ftl.
>  Please review your changes in order to incorporate them into
> >>> JsLanguageFilesMappingCreator::createJsLanguageFileMapping
>  TIA
> 
>  Jacques
> 
>

Re: JsLanguageFilesMappingCreator.java

[Jacques Le Roux]

Thanks Suraj,

Pushed with slight changes

Jacques

Le 27/08/2020 à 13:37, Jacques Le Roux a écrit :

Sure I'll, it's long ago but I still remember the difficulties ;)

Jacques

Le 27/08/2020 à 12:59, Suraj Khurana a écrit :

Thanks Jacques.

I have attached a patch at https://issues.apache.org/jira/browse/OFBIZ-11926
Could you please review it?

TIA.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Thu, Aug 27, 2020 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


James,

Seems you are not concerned. Because with OFBIZ-11958 you created
JsLanguageFilesMappingTransform.java.
And it's not, and does not need to be, generated by
JsLanguageFilesMappingCreator::createJsLanguageFileMapping

If you agree you need to put an ASL2 header in it.
And I'll revert
https://github.com/apache/ofbiz-framework/commit/707acc7d2744c32519aab67e78b8e0e293cb01d6/

TIA

Jacques

Le 27/08/2020 à 11:54, Jacques Le Roux a écrit :

Hi James, Suraj,

As it's documented inside

JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by the
createJsLanguageFileMapping service to "create

or update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl

files."

This happens when we update the languages used by some JavaScript

plugins, notably those:

"/common/common-theme/webapp/js/jquery/ui/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/datejs/"
"/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
"/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"

We then must manually run the createJsLanguageFileMapping service.

So we should not modify JsLanguageFilesMapping.java and

JsLanguageFilesMapping.ftl but modify

JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to

correctly generate them.

You both have recently modified JsLanguageFilesMapping.java or/and

JsLanguageFilesMapping.ftl.

Please review your changes in order to incorporate them into

JsLanguageFilesMappingCreator::createJsLanguageFileMapping

TIA

Jacques

Re: [OFBIZ-11976] svg files not removed on clean

[Jacques Le Roux]

Thanks Girish!

I'll have a look...

Jacques

Le 27/08/2020 à 14:21, Girish Vasmatkar a écrit :

Hi Jacques

When you run "gradlew generateAllPluginsDocumentation", all "actions"
defined in the task '"generateAllPluginsDocumentation" get executed as part
of execution phase. doFirst and doLast are the actions defined hence they
get executed.

And when you run any other tasks, all tasks present in the project
(including subprojects) are just configured not executed*. *So when we run
say ./gradlew config, everything that is not defined an an action (doFirst,
doLast or any other action) gets executed as part of configuration phase
for generateAllPluginsDocumentation task.

doLast { delete "${component}/src/docs/asciidoc/images/OFBiz-Logo.svg" }
Above is supposed to be executed during execution phase of the task
because doLast is an action for the task.  If you define your print
statements inside doLast, you won't see it printed if you run any other
task.

The problem is the part that is generating the docs, should be defined in
an action but at present is part of configuration. That's why when other
tasks run, docs are generated but never deleted (deletion part being
defined in doLast).

Best Regards,
- Girish

Re: [OFBIZ-11976] svg files not removed on clean

[Girish Vasmatkar]

Hi Jacques

When you run "gradlew generateAllPluginsDocumentation", all "actions"
defined in the task '"generateAllPluginsDocumentation" get executed as part
of execution phase. doFirst and doLast are the actions defined hence they
get executed.

And when you run any other tasks, all tasks present in the project
(including subprojects) are just configured not executed*. *So when we run
say ./gradlew config, everything that is not defined an an action (doFirst,
doLast or any other action) gets executed as part of configuration phase
for generateAllPluginsDocumentation task.

doLast { delete "${component}/src/docs/asciidoc/images/OFBiz-Logo.svg" }
Above is supposed to be executed during execution phase of the task
because doLast is an action for the task.  If you define your print
statements inside doLast, you won't see it printed if you run any other
task.

The problem is the part that is generating the docs, should be defined in
an action but at present is part of configuration. That's why when other
tasks run, docs are generated but never deleted (deletion part being
defined in doLast).

Best Regards,
- Girish

Re: [OFBIZ-11976] svg files not removed on clean

[Jacques Le Roux]

Thanks Girish,

Yes, I found that too.

The weird part is if I run "gradlew generateAllPluginsDocumentation" then the 
OFBiz-Logo.svg in plugins are deleted. Not when I run any other task.

So it seems that config does not run completely the tasks. But if I put a

println("==")

just above

doLast { delete "${component}/src/docs/asciidoc/images/OFBiz-Logo.svg" }

Then running any tasks show the println.

So why Gradle does not then run

doLast { delete "${component}/src/docs/asciidoc/images/OFBiz-Logo.svg" }

is still a mystery to me.

Could be the component part missing. But it does not make more sense to me :D

Jacques

Le 27/08/2020 à 12:16, Girish Vasmatkar a écrit :

Hi Jacques -

This explains it nicely -
https://blog.softwaremill.com/my-task-whats-wrong-with-your-gradle-task-82312100c595

Turns out that gradle's configuration phase appears to be "running" the
tasks.

Best,
Girish




On Thu, Aug 27, 2020 at 3:12 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

While looking at this issue I found that a simple "gradlew config"
generates the files which are used by generatePluginDocumentation and
generateAllPluginsDocumentation.

So somehow these tasks are "activated" just launching any task. Does
somebody knows why it's so?

Thanks

Jacques

Re: JsLanguageFilesMappingCreator.java

[Jacques Le Roux]

Sure I'll, it's long ago but I still remember the difficulties ;)

Jacques

Le 27/08/2020 à 12:59, Suraj Khurana a écrit :

Thanks Jacques.

I have attached a patch at https://issues.apache.org/jira/browse/OFBIZ-11926
Could you please review it?

TIA.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Thu, Aug 27, 2020 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


James,

Seems you are not concerned. Because with OFBIZ-11958 you created
JsLanguageFilesMappingTransform.java.
And it's not, and does not need to be, generated by
JsLanguageFilesMappingCreator::createJsLanguageFileMapping

If you agree you need to put an ASL2 header in it.
And I'll revert
https://github.com/apache/ofbiz-framework/commit/707acc7d2744c32519aab67e78b8e0e293cb01d6/

TIA

Jacques

Le 27/08/2020 à 11:54, Jacques Le Roux a écrit :

Hi James, Suraj,

As it's documented inside

JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by the
createJsLanguageFileMapping service to "create

or update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl

files."

This happens when we update the languages used by some JavaScript

plugins, notably those:

"/common/common-theme/webapp/js/jquery/ui/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/datejs/"
"/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
"/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"

We then must manually run the createJsLanguageFileMapping service.

So we should not modify JsLanguageFilesMapping.java and

JsLanguageFilesMapping.ftl but modify

JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to

correctly generate them.

You both have recently modified JsLanguageFilesMapping.java or/and

JsLanguageFilesMapping.ftl.

Please review your changes in order to incorporate them into

JsLanguageFilesMappingCreator::createJsLanguageFileMapping

TIA

Jacques

Re: JsLanguageFilesMappingCreator.java

[Suraj Khurana]

Thanks Jacques.

I have attached a patch at https://issues.apache.org/jira/browse/OFBIZ-11926
Could you please review it?

TIA.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Thu, Aug 27, 2020 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> James,
>
> Seems you are not concerned. Because with OFBIZ-11958 you created
> JsLanguageFilesMappingTransform.java.
> And it's not, and does not need to be, generated by
> JsLanguageFilesMappingCreator::createJsLanguageFileMapping
>
> If you agree you need to put an ASL2 header in it.
> And I'll revert
> https://github.com/apache/ofbiz-framework/commit/707acc7d2744c32519aab67e78b8e0e293cb01d6/
>
> TIA
>
> Jacques
>
> Le 27/08/2020 à 11:54, Jacques Le Roux a écrit :
> > Hi James, Suraj,
> >
> > As it's documented inside
> JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by the
> createJsLanguageFileMapping service to "create
> > or update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl
> files."
> >
> > This happens when we update the languages used by some JavaScript
> plugins, notably those:
> >
> > "/common/common-theme/webapp/js/jquery/ui/i18n/"
> > "/common/common-theme/webapp/js/jquery/plugins/datejs/"
> > "/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
> > "/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
> > "/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"
> >
> > We then must manually run the createJsLanguageFileMapping service.
> >
> > So we should not modify JsLanguageFilesMapping.java and
> JsLanguageFilesMapping.ftl but modify
> > JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to
> correctly generate them.
> >
> > You both have recently modified JsLanguageFilesMapping.java or/and
> JsLanguageFilesMapping.ftl.
> > Please review your changes in order to incorporate them into
> JsLanguageFilesMappingCreator::createJsLanguageFileMapping
> >
> > TIA
> >
> > Jacques
> >
>

Re: [OFBIZ-11976] svg files not removed on clean

[Girish Vasmatkar]

Hi Jacques -

This explains it nicely -
https://blog.softwaremill.com/my-task-whats-wrong-with-your-gradle-task-82312100c595

Turns out that gradle's configuration phase appears to be "running" the
tasks.

Best,
Girish




On Thu, Aug 27, 2020 at 3:12 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> While looking at this issue I found that a simple "gradlew config"
> generates the files which are used by generatePluginDocumentation and
> generateAllPluginsDocumentation.
>
> So somehow these tasks are "activated" just launching any task. Does
> somebody knows why it's so?
>
> Thanks
>
> Jacques
>
>

Re: JsLanguageFilesMappingCreator.java

[Jacques Le Roux]

James,

Seems you are not concerned. Because with OFBIZ-11958 you created 
JsLanguageFilesMappingTransform.java.
And it's not, and does not need to be, generated by 
JsLanguageFilesMappingCreator::createJsLanguageFileMapping

If you agree you need to put an ASL2 header in it.
And I'll revert 
https://github.com/apache/ofbiz-framework/commit/707acc7d2744c32519aab67e78b8e0e293cb01d6/

TIA

Jacques

Le 27/08/2020 à 11:54, Jacques Le Roux a écrit :

Hi James, Suraj,

As it's documented inside JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by the createJsLanguageFileMapping service to "create 
or update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl files."


This happens when we update the languages used by some JavaScript plugins, 
notably those:

"/common/common-theme/webapp/js/jquery/ui/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/datejs/"
"/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
"/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"

We then must manually run the createJsLanguageFileMapping service.

So we should not modify JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl but modify 
JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to correctly generate them.


You both have recently modified JsLanguageFilesMapping.java or/and 
JsLanguageFilesMapping.ftl.
Please review your changes in order to incorporate them into 
JsLanguageFilesMappingCreator::createJsLanguageFileMapping

TIA

Jacques

JsLanguageFilesMappingCreator.java

[Jacques Le Roux]

Hi James, Suraj,

As it's documented inside JsLanguageFilesMappingCreator::createJsLanguageFileMapping is used by the createJsLanguageFileMapping service to "create or 
update JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl files."


This happens when we update the languages used by some JavaScript plugins, 
notably those:

"/common/common-theme/webapp/js/jquery/ui/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/datejs/"
"/common/common-theme/webapp/js/jquery/plugins/validate/localization/"
"/common/common-theme/webapp/js/jquery/plugins/datetimepicker/i18n/"
"/common/common-theme/webapp/js/jquery/plugins/select2/js/i18n/"

We then must manually run the createJsLanguageFileMapping service.

So we should not modify JsLanguageFilesMapping.java and JsLanguageFilesMapping.ftl but modify 
JsLanguageFilesMappingCreator::createJsLanguageFileMapping in order to correctly generate them.


You both have recently modified JsLanguageFilesMapping.java or/and 
JsLanguageFilesMapping.ftl.
Please review your changes in order to incorporate them into 
JsLanguageFilesMappingCreator::createJsLanguageFileMapping

TIA

Jacques

[OFBIZ-11976] svg files not removed on clean

[Jacques Le Roux]

Hi,

While looking at this issue I found that a simple "gradlew config" generates the files which are used by generatePluginDocumentation and 
generateAllPluginsDocumentation.


So somehow these tasks are "activated" just launching any task. Does somebody 
knows why it's so?

Thanks

Jacques

Re: A little bit of Lombok

[Jacques Le Roux]

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 版邮件应用

发件人: Daniel Watford
发送时间: 2020年7月28日 20:44
收件人: 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