Re: Ordermgr errors on demo-trunk.ofbiz.apache.org

[Pierre Smits]

Thanks Pawan, for the quick action.

Op za 23 mei 2020 20:16 schreef Pawan Verma :

> Hello Everyone,
>
> I dig around the issue and found that getPartyNameForDate is the main
> culprit for this issue. It can be easily generated on the local instance by
> updating the admin's name.
>
> Updating name will create a new record in PartyNameHistory entity and
> service getPartyNameForDate has an issue while trying to fetch the name.
>
> The reason for this issue is code is trying to get the gender of a person
> from partyNameHistory record and gender is not a field in the
> partyNameHistory entity. During conversion we minimized duplicate code
> which caused that issue. Conversion is done under OFBIZ-11361.
>
> I've added a check to avoid checking gender in the partyNameHistory record
> at 3f9e377 under OFBIZ-11736.
>
> A special thanks to Unknown person who tried to update the admin's name and
> due to which we got this error :)
>
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
> On Sat, May 23, 2020 at 8:28 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi Pawan,
> >
> > It seems related to this error:
> >
> > Caused by: org.apache.ofbiz.service.GenericServiceException: Error
> running
> > Groovy method [getPartyNameForDate] in Groovy file
> > [component://party/groovyScripts/party/PartyServices.groovy]: (The field
> > name (or key) [gender] is not valid for entity [PartyNameHistory].)
> >
> > But I updated locally to HEAD and can't reproduce either
> >
> > It could be related to OFBIZ-11506 but that's 5 weeks ago, so I doubt.
> > Maybe someone screwed the data on trunk demo. How I have no ideas.
> >
> > Also when I get to ordermgr on trunk demo, the 1st error I get in log is:
> >
> > - Failed at: #assign billToPartyNameResult = dispa...  [in template
> > "component://order/template/order/OrderListByDate.ftl" at line 51, column
> > 13]
> >
> > At this stage I think it's better to wait tomorrow morning to see if it
> > reproduces. But yes something seems wrong with data and that's not
> normal.
> >
> > HTH
> >
> > Jacques
> >
> > Le 23/05/2020 à 16:27, Pawan Verma a écrit :
> > > Hello Devs,
> > >
> > > Just saw some unusual errors on demo-trunk.ofbiz.apache.org for
> ordermgr
> > > component. Most of the Order screens are broken.
> > >
> > > At first glance, it seems some deployment issues because most of the
> > > screens are broken. At my local, after the latest update these screens
> > seem
> > > to be working fine.
> > >
> > > Does anyone know about it? TIA
> >
> >
>

Re: Ordermgr errors on demo-trunk.ofbiz.apache.org

[Pawan Verma]

Hello Everyone,

I dig around the issue and found that getPartyNameForDate is the main
culprit for this issue. It can be easily generated on the local instance by
updating the admin's name.

Updating name will create a new record in PartyNameHistory entity and
service getPartyNameForDate has an issue while trying to fetch the name.

The reason for this issue is code is trying to get the gender of a person
from partyNameHistory record and gender is not a field in the
partyNameHistory entity. During conversion we minimized duplicate code
which caused that issue. Conversion is done under OFBIZ-11361.

I've added a check to avoid checking gender in the partyNameHistory record
at 3f9e377 under OFBIZ-11736.

A special thanks to Unknown person who tried to update the admin's name and
due to which we got this error :)

-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Sat, May 23, 2020 at 8:28 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pawan,
>
> It seems related to this error:
>
> Caused by: org.apache.ofbiz.service.GenericServiceException: Error running
> Groovy method [getPartyNameForDate] in Groovy file
> [component://party/groovyScripts/party/PartyServices.groovy]: (The field
> name (or key) [gender] is not valid for entity [PartyNameHistory].)
>
> But I updated locally to HEAD and can't reproduce either
>
> It could be related to OFBIZ-11506 but that's 5 weeks ago, so I doubt.
> Maybe someone screwed the data on trunk demo. How I have no ideas.
>
> Also when I get to ordermgr on trunk demo, the 1st error I get in log is:
>
> - Failed at: #assign billToPartyNameResult = dispa...  [in template
> "component://order/template/order/OrderListByDate.ftl" at line 51, column
> 13]
>
> At this stage I think it's better to wait tomorrow morning to see if it
> reproduces. But yes something seems wrong with data and that's not normal.
>
> HTH
>
> Jacques
>
> Le 23/05/2020 à 16:27, Pawan Verma a écrit :
> > Hello Devs,
> >
> > Just saw some unusual errors on demo-trunk.ofbiz.apache.org for ordermgr
> > component. Most of the Order screens are broken.
> >
> > At first glance, it seems some deployment issues because most of the
> > screens are broken. At my local, after the latest update these screens
> seem
> > to be working fine.
> >
> > Does anyone know about it? TIA
>
>

Re: LineLength for checkstyle

[Pawan Verma]

+1

Pawan

Re: LineLength for checkstyle

[Jacques Le Roux]

+1

Jacques

Le 23/05/2020 à 17:29, Suraj Khurana a écrit :

Hello Devs,

Recently we are facing some checkstyle issues and one cause of it is
LineLength property.
Currently we have set it to 120, I think we should make it to 150 instead.
It is pretty visible in 13/14 font sizes as well.

Please share your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

LineLength for checkstyle

[Suraj Khurana]

Hello Devs,

Recently we are facing some checkstyle issues and one cause of it is
LineLength property.
Currently we have set it to 120, I think we should make it to 150 instead.
It is pretty visible in 13/14 font sizes as well.

Please share your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: Ordermgr errors on demo-trunk.ofbiz.apache.org

[Jacques Le Roux]

Hi Pawan,

It seems related to this error:

Caused by: org.apache.ofbiz.service.GenericServiceException: Error running Groovy method [getPartyNameForDate] in Groovy file 
[component://party/groovyScripts/party/PartyServices.groovy]: (The field name (or key) [gender] is not valid for entity [PartyNameHistory].)


But I updated locally to HEAD and can't reproduce either

It could be related to OFBIZ-11506 but that's 5 weeks ago, so I doubt. Maybe 
someone screwed the data on trunk demo. How I have no ideas.

Also when I get to ordermgr on trunk demo, the 1st error I get in log is:

- Failed at: #assign billToPartyNameResult = dispa...  [in template 
"component://order/template/order/OrderListByDate.ftl" at line 51, column 13]

At this stage I think it's better to wait tomorrow morning to see if it 
reproduces. But yes something seems wrong with data and that's not normal.

HTH

Jacques

Le 23/05/2020 à 16:27, Pawan Verma a écrit :

Hello Devs,

Just saw some unusual errors on demo-trunk.ofbiz.apache.org for ordermgr
component. Most of the Order screens are broken.

At first glance, it seems some deployment issues because most of the
screens are broken. At my local, after the latest update these screens seem
to be working fine.

Does anyone know about it? TIA

Re: Ordermgr errors on demo-trunk.ofbiz.apache.org

[Jacques Le Roux]

Hi Pawan,

It seems related to this error:

Caused by: org.apache.ofbiz.service.GenericServiceException: Error running Groovy method [getPartyNameForDate] in Groovy file 
[component://party/groovyScripts/party/PartyServices.groovy]: (The field name (or key) [gender] is not valid for entity [PartyNameHistory].)


But I updated locally to HEAD and can't reproduce either

It could be related to OFBIZ-11506 but that's 5 weeks ago, so I doubt. Maybe 
someone screwed the data on trunk demo. How I have no ideas.

Also when I get to ordermgr on trunk demo, the 1st error I get in log is:

- Failed at: #assign billToPartyNameResult = dispa...  [in template 
"component://order/template/order/OrderListByDate.ftl" at line 51, column 13]

HTH

Jacques

Le 23/05/2020 à 16:27, Pawan Verma a écrit :

Hello Devs,

Just saw some unusual errors on demo-trunk.ofbiz.apache.org for ordermgr
component. Most of the Order screens are broken.

At first glance, it seems some deployment issues because most of the
screens are broken. At my local, after the latest update these screens seem
to be working fine.

Does anyone know about it? TIA

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Suraj Khurana]

+1 Aditya

If we can do that, that would be great.

--
Suraj khurana


On Sat 23 May, 2020, 6:55 PM Aditya Sharma,  wrote:

> Hi Jacques,
>
> I think *check styles* plugin is important for us and we should think of
> introducing a pre-commit hook that checks only for the staged changes. This
> will help developers to know about the lint issues before the commit
> itself.
>
> Some reference I found that achieves the above case. Though I didn't try
> any of these solutions.
>
>
> https://ebaytech.berlin/checkstyle-on-changed-files-with-gradle-1619e49dbe4e
>
> https://stackoverflow.com/questions/43730901/is-there-a-way-to-run-checkstyle-on-only-files-that-have-changes-in-vcs
>
> https://ealebed.github.io/posts/2020/gradle-checkstyle-on-changed-files-only/
>
> What do you think?
>
> Thanks and Regards,
> Aditya Sharma
>
> On Sat, May 23, 2020 at 6:44 PM Pawan Verma  >
> wrote:
>
> > Hi Jacques,
> >
> > I care for the *checkstyle* issues but I also feel we should abandon it.
> >
> > --
> > Thanks & Regards
> > Pawan Verma
> > Technical Consultant
> > *HotWax Systems*
> > *Enterprise open source experts*
> > http://www.hotwaxsystems.com
> >
> >
> > On Sat, May 23, 2020 at 6:08 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Ha wait I confused w/ something else.
> > >
> > > Aas I said when starting this thread
> > >
> > > "this is a *checkstyle* issue. It's not clear to me why it
> happened."
> > >
> > > Currently BuildBot makes erratic exceptions trying to pull. I have
> > created
> > > for that (and just updated)
> > > https://issues.apache.org/jira/browse/INFRA-20303
> > >
> > > So it's maybe not only your commit which increased the style errors...
> > >
> > > Unfortunately in this case, as it's then difficult to know form where
> > > comes the errors (they can be cumulated commit after commit), the
> easier
> > > issue
> > > is to set tasks.checkstyleMain.maxErrors to the last reported errors :/
> > >
> > > Now I have also mentioned in the 1st msg of this thread:
> > >
> > > "Also I begin to wonder if the community really cares about
> > > *checkstyle* issues..."
> > >
> > > I mean we could maybe abandon it since it seems I'm the only one to
> > care...
> > >
> > > HTH
> > >
> > > Jacques
> > >
> > > Le 23/05/2020 à 14:23, Jacques Le Roux a écrit :
> > > > Thanks Suraj!
> > > >
> > > > Jacques
> > > >
> > > > Le 23/05/2020 à 14:04, Suraj Khurana a écrit :
> > > >> Hello team,
> > > >>
> > > >> All tests passed on my local machine.
> > > >>
> > > >> I used: ./gradlew testIntegration
> > > >>
> > > >> --
> > > >> Best Regards,
> > > >> Suraj Khurana
> > > >> Senior Technical Consultant
> > > >>
> > > >>
> > > >> On Sat, May 23, 2020 at 5:17 PM  wrote:
> > > >>
> > > >>> 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/1396
> > > >>>
> > > >>> Buildbot URL: https://ci.apache.org/
> > > >>>
> > > >>> Buildslave for this Build: asf947_ubuntu
> > > >>>
> > > >>> Build Reason: downstream
> > > >>> Build Source Stamp: [branch trunk]
> > > 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
> > > >>> Blamelist: Suraj Khurana <
> > > 64310724+surajkhur...@users.noreply.github.com>,Suraj
> > > >>> Khurana 
> > > >>>
> > > >>> BUILD FAILED: failed shell_2
> > > >>>
> > > >>> Sincerely,
> > > >>>   -The Buildbot
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > >
> >
>

Ordermgr errors on demo-trunk.ofbiz.apache.org

[Pawan Verma]

Hello Devs,

Just saw some unusual errors on demo-trunk.ofbiz.apache.org for ordermgr
component. Most of the Order screens are broken.

At first glance, it seems some deployment issues because most of the
screens are broken. At my local, after the latest update these screens seem
to be working fine.

Does anyone know about it? TIA
-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Aditya Sharma]

Hi Jacques,

I think *check styles* plugin is important for us and we should think of
introducing a pre-commit hook that checks only for the staged changes. This
will help developers to know about the lint issues before the commit itself.

Some reference I found that achieves the above case. Though I didn't try
any of these solutions.

https://ebaytech.berlin/checkstyle-on-changed-files-with-gradle-1619e49dbe4e
https://stackoverflow.com/questions/43730901/is-there-a-way-to-run-checkstyle-on-only-files-that-have-changes-in-vcs
https://ealebed.github.io/posts/2020/gradle-checkstyle-on-changed-files-only/

What do you think?

Thanks and Regards,
Aditya Sharma

On Sat, May 23, 2020 at 6:44 PM Pawan Verma 
wrote:

> Hi Jacques,
>
> I care for the *checkstyle* issues but I also feel we should abandon it.
>
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
> On Sat, May 23, 2020 at 6:08 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Ha wait I confused w/ something else.
> >
> > Aas I said when starting this thread
> >
> > "this is a *checkstyle* issue. It's not clear to me why it happened."
> >
> > Currently BuildBot makes erratic exceptions trying to pull. I have
> created
> > for that (and just updated)
> > https://issues.apache.org/jira/browse/INFRA-20303
> >
> > So it's maybe not only your commit which increased the style errors...
> >
> > Unfortunately in this case, as it's then difficult to know form where
> > comes the errors (they can be cumulated commit after commit), the easier
> > issue
> > is to set tasks.checkstyleMain.maxErrors to the last reported errors :/
> >
> > Now I have also mentioned in the 1st msg of this thread:
> >
> > "Also I begin to wonder if the community really cares about
> > *checkstyle* issues..."
> >
> > I mean we could maybe abandon it since it seems I'm the only one to
> care...
> >
> > HTH
> >
> > Jacques
> >
> > Le 23/05/2020 à 14:23, Jacques Le Roux a écrit :
> > > Thanks Suraj!
> > >
> > > Jacques
> > >
> > > Le 23/05/2020 à 14:04, Suraj Khurana a écrit :
> > >> Hello team,
> > >>
> > >> All tests passed on my local machine.
> > >>
> > >> I used: ./gradlew testIntegration
> > >>
> > >> --
> > >> Best Regards,
> > >> Suraj Khurana
> > >> Senior Technical Consultant
> > >>
> > >>
> > >> On Sat, May 23, 2020 at 5:17 PM  wrote:
> > >>
> > >>> 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/1396
> > >>>
> > >>> Buildbot URL: https://ci.apache.org/
> > >>>
> > >>> Buildslave for this Build: asf947_ubuntu
> > >>>
> > >>> Build Reason: downstream
> > >>> Build Source Stamp: [branch trunk]
> > 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
> > >>> Blamelist: Suraj Khurana <
> > 64310724+surajkhur...@users.noreply.github.com>,Suraj
> > >>> Khurana 
> > >>>
> > >>> BUILD FAILED: failed shell_2
> > >>>
> > >>> Sincerely,
> > >>>   -The Buildbot
> > >>>
> > >>>
> > >>>
> > >>>
> >
>

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Pawan Verma]

Hi Jacques,

I care for the *checkstyle* issues but I also feel we should abandon it.

-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Sat, May 23, 2020 at 6:08 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Ha wait I confused w/ something else.
>
> Aas I said when starting this thread
>
> "this is a *checkstyle* issue. It's not clear to me why it happened."
>
> Currently BuildBot makes erratic exceptions trying to pull. I have created
> for that (and just updated)
> https://issues.apache.org/jira/browse/INFRA-20303
>
> So it's maybe not only your commit which increased the style errors...
>
> Unfortunately in this case, as it's then difficult to know form where
> comes the errors (they can be cumulated commit after commit), the easier
> issue
> is to set tasks.checkstyleMain.maxErrors to the last reported errors :/
>
> Now I have also mentioned in the 1st msg of this thread:
>
> "Also I begin to wonder if the community really cares about
> *checkstyle* issues..."
>
> I mean we could maybe abandon it since it seems I'm the only one to care...
>
> HTH
>
> Jacques
>
> Le 23/05/2020 à 14:23, Jacques Le Roux a écrit :
> > Thanks Suraj!
> >
> > Jacques
> >
> > Le 23/05/2020 à 14:04, Suraj Khurana a écrit :
> >> Hello team,
> >>
> >> All tests passed on my local machine.
> >>
> >> I used: ./gradlew testIntegration
> >>
> >> --
> >> Best Regards,
> >> Suraj Khurana
> >> Senior Technical Consultant
> >>
> >>
> >> On Sat, May 23, 2020 at 5:17 PM  wrote:
> >>
> >>> 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/1396
> >>>
> >>> Buildbot URL: https://ci.apache.org/
> >>>
> >>> Buildslave for this Build: asf947_ubuntu
> >>>
> >>> Build Reason: downstream
> >>> Build Source Stamp: [branch trunk]
> 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
> >>> Blamelist: Suraj Khurana <
> 64310724+surajkhur...@users.noreply.github.com>,Suraj
> >>> Khurana 
> >>>
> >>> BUILD FAILED: failed shell_2
> >>>
> >>> Sincerely,
> >>>   -The Buildbot
> >>>
> >>>
> >>>
> >>>
>

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Ha wait I confused w/ something else.

Aas I said when starting this thread

   "this is a *checkstyle* issue. It's not clear to me why it happened."

Currently BuildBot makes erratic exceptions trying to pull. I have created for 
that (and just updated) https://issues.apache.org/jira/browse/INFRA-20303

So it's maybe not only your commit which increased the style errors...

Unfortunately in this case, as it's then difficult to know form where comes the errors (they can be cumulated commit after commit), the easier issue 
is to set tasks.checkstyleMain.maxErrors to the last reported errors :/


Now I have also mentioned in the 1st msg of this thread:

   "Also I begin to wonder if the community really cares about *checkstyle* 
issues..."

I mean we could maybe abandon it since it seems I'm the only one to care...

HTH

Jacques

Le 23/05/2020 à 14:23, Jacques Le Roux a écrit :

Thanks Suraj!

Jacques

Le 23/05/2020 à 14:04, Suraj Khurana a écrit :

Hello team,

All tests passed on my local machine.

I used: ./gradlew testIntegration

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, May 23, 2020 at 5:17 PM  wrote:


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/1396

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: downstream
Build Source Stamp: [branch trunk] 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
Blamelist: Suraj Khurana <64310724+surajkhur...@users.noreply.github.com>,Suraj
Khurana 

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Thanks Suraj!

Jacques

Le 23/05/2020 à 14:04, Suraj Khurana a écrit :

Hello team,

All tests passed on my local machine.

I used: ./gradlew testIntegration

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, May 23, 2020 at 5:17 PM  wrote:


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/1396

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: downstream
Build Source Stamp: [branch trunk] 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
Blamelist: Suraj Khurana <64310724+surajkhur...@users.noreply.github.com>,Suraj
Khurana 

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Suraj Khurana]

Hello team,

All tests passed on my local machine.

I used: ./gradlew testIntegration

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, May 23, 2020 at 5:17 PM  wrote:

> 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/1396
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: asf947_ubuntu
>
> Build Reason: downstream
> Build Source Stamp: [branch trunk] 8bdb6c99856fd4ae17a95ccb0f661a256caaab13
> Blamelist: Suraj Khurana 
> <64310724+surajkhur...@users.noreply.github.com>,Suraj
> Khurana 
>
> BUILD FAILED: failed shell_2
>
> Sincerely,
>  -The Buildbot
>
>
>
>

Re: @deprecated No replacement

[Aditya Sharma]

+1 Thanks Jacques!

Thanks and Regards,
Aditya Sharma

On Sat, May 23, 2020 at 12:13 PM Pierre Smits 
wrote:

> +1 forellen removing refs
>
> Op za 23 mei 2020 08:27 schreef Devanshu Vyas :
>
> > +1 to remove references.
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Sat, May 23, 2020 at 11:54 AM Mridul Pathak <
> > mridul.pat...@hotwaxsystems.com> wrote:
> >
> > > +1 to remove references.
> > >
> > > Thanks.
> > > --
> > > Mridul Pathak
> > >
> > >
> > > > On 22-May-2020, at 1:03 PM, Jacques Le Roux <
> > > jacques.le.r...@les7arts.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > We have 5, 8 years old, , "@deprecated No replacement" references in
> > > Java code:
> > > >
> > https://ofbiz.markmail.org/search/?q=%22%40deprecated+No+replacement%22
> > > >
> > > > It seems they are all related to Minilang.  I think we should either
> > > remove the concerned methods.
> > > >
> > > > Or rather, easier, remove the "@deprecated No replacement" references
> > > since anyway Minilang is deprecated as a whole.
> > > >
> > > > I'm for the later and will do so in a week if nobody is against.
> > > >
> > > > Jacques
> > > >
> > >
> > >
> >
>

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Jacques Le Roux]

Hi Olivier:

It's only in R17, see content of a 
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins build

If you want to know more look at 'f_ofb_branch17_framework_plugins' in 
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf/ (only committers)


All builds mention: "The Documentation is only generated for the next stable 
version, at the moment R17"

Jobs to do are:

Adds the same in trunk and R18

And especially before ask the same than in https://issues.apache.org/jira/browse/INFRA-17258 distinguishing each case. Better call them stable, next 
and trunk than R17, R18 and trunk (OK trunk never "change" ;) )...


HTH

Jacques

Le 23/05/2020 à 11:27, Olivier Heintz a écrit :

Thanks Jacques for the clarification,

But, I'm not sure to understand,
currently, doc is generated only for R17 and are only included in buildbot job 
for trunkFrameworkPlugin  ?
Work to do is to add for job R17Framework and R18Framework ?
Infra help is needed to publish for multi-release ?

can I help about one of these points ?

Olivier

Le 20/05/2020 à 17:15, Jacques Le Roux a écrit :

Thanks Olivier,

I must add that it's the current location and it would need more work to change 
it, notably Infra help

Jacques

Le 20/05/2020 à 16:24, Olivier Heintz a écrit :

Yes, of course

My explanation was not clear, I propose to have one documentation by release 
and use it in the relative help

My question is more about using (or not) 
ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc

Le 20/05/2020 à 08:32, Michael Brohl a écrit :

Hi Olivier,

wouldn't it be better to have different documentation paths for the
different branches?

If we would show the trunk documentation/help for stable branches, it
will most likely be wrong in some cases.

Another thought: it would be great if we could have the docs available
at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 19.05.20 um 11:54 schrieb Olivier Heintz:

Hi Community,

I need some comment or thought about one of point of the solution proposed.

Is there some people against the fact of used 
ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for the 
ofbiz help ?

As I explained in my previous email, ci.apache.org/projects/ofbiz/site/ofbizdoc 
would be the default value for userDocUri, (but value in
general.properties can be change with the local place of doc generation).

If community think, it's a good step solution (on the road to the new help 
system), I will create a JIRA for generating the doc on all supported
branches (currently, it's only done for r17)

I just finished to migrate AccountingHelpData.xml to added the 
Jira 11693 created with a patch proposed

if this solution is accepted, (and all asciidoc integrated) next step is to 
work component by component
For each:
1. add in the component decorator 
Hi community,

First step about Docbook migration to asciidoc is done, all existing files have 
been converted
(waiting a review before PR merge)

Next step is to have a new help system,

I propose to do a very simple solution which would be a link to a documentation 
site.
This solution would use
 1. at ofbiz level, a default proprety for documentation website uri
 2. at the screen level
   * it would be possible to give a other uri (for user documentation)
   * if the anchor in the user documentation for this screen is put, the 
new help is used otherwise the older link is used

If this solution is validated, next step will be to update all the screens with 
the correct link value

I propose to create the Jira (and the implmentation) with this very simple 
solution (using the doc generated by Buildbot as documentation site)
when some other people with a good knowledge of gradle and/or ofbiz cms have 
time to do a internal documentation website, it will be possible to
change the default uri ;-)

what's your opinion about ?


Le 26/02/2020 à 17:10, Olivier Heintz a écrit :

inline

Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :

Hello Olivier,

Without digging into much detail, I can say that it's a good idea to
switch the online help system to asciidoc.

The current structure of asciidoc templates is designed to be a full
manual document. To link up different pages to different sections, you
need to break the documentation down to smaller files and then combine
them. This way you can have both the "big" manual and the "per screen"
help section.

In my experience, as I'm working with
 - current ofbiz online help
 - ofbiz webhelp
 - some static doc website done with Grav (build with multiple small files)
 - some static doc website done with asciidoc (only one large file)
 - ...

With multiple small files it's needed to have a very good search engine and a 
global index / TOC

With the One page doc, the TOC is very large and not always very convenient, 
but exist and the 

Re: [GitHub] [ofbiz-framework] sonarcloud[bot] removed a comment on pull request #117: Improved: Update Data Sets

[Pierre Smits]

Thanks Jacques, forellen staking care of thuis.

Op za 23 mei 2020 11:28 schreef Jacques Le Roux <
jacques.le.r...@les7arts.com>:

> Actually we have also this information nicely coming to ofbiz-*@
> noreply.github.com
>
> So we don't need the ugly couples (added then removed) at
> notificati...@ofbiz.apache.org
>
> If nobody disagree I'll see if Infra can do something about that in a
> week...
>
> Jacques
>
> Le 20/05/2020 à 20:24, Pierre Smits a écrit :
> > It happened to me a few times that a PR didn't pass the quality gates of
> > SonarCloud. And it helped me to correct the situation on a next push
> >
> > RE: BTW is a PR pushable if the SonarCloud tests don't  pass?
> > SonarCloud tests are done AFTER the PR is created. Then it checks on
> every
> > commit coming in from where the PR was originated.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz 
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > Apache Steve , committer
> >
> >
> > On Wed, May 20, 2020 at 8:15 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> For me both are useless, I have never seen a SonarCloud Quality Gate not
> >> passing and this information is visible on the PR before pushing it
> >>
> >> BTW is a PR pushable if the SonarCloud tests don't  pass?
> >>
> >> I could filter them, but by experience I tend to privilege cutting at
> >> root. Because maintainer email filters is not my cup of tea.
> >>
> >> Jacques
> >>
> >> Le 20/05/2020 à 19:54, Pawan Verma a écrit :
> >>> Hi Pierre,
> >>>
> >>> For me, this one is good --> Kudos, SonarCloud Quality Gate passed!
> >>>
> >>> This one seems to be useless --> sonarcloud[bot] removed a comment on
> >> pull
> >>> request
> >>
>

Re: [GitHub] [ofbiz-framework] sonarcloud[bot] removed a comment on pull request #117: Improved: Update Data Sets

[Jacques Le Roux]

Actually we have also this information nicely coming to 
ofbiz-*@noreply.github.com

So we don't need the ugly couples (added then removed) at 
notificati...@ofbiz.apache.org

If nobody disagree I'll see if Infra can do something about that in a week...

Jacques

Le 20/05/2020 à 20:24, Pierre Smits a écrit :

It happened to me a few times that a PR didn't pass the quality gates of
SonarCloud. And it helped me to correct the situation on a next push

RE: BTW is a PR pushable if the SonarCloud tests don't  pass?
SonarCloud tests are done AFTER the PR is created. Then it checks on every
commit coming in from where the PR was originated.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Wed, May 20, 2020 at 8:15 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


For me both are useless, I have never seen a SonarCloud Quality Gate not
passing and this information is visible on the PR before pushing it

BTW is a PR pushable if the SonarCloud tests don't  pass?

I could filter them, but by experience I tend to privilege cutting at
root. Because maintainer email filters is not my cup of tea.

Jacques

Le 20/05/2020 à 19:54, Pawan Verma a écrit :

Hi Pierre,

For me, this one is good --> Kudos, SonarCloud Quality Gate passed!

This one seems to be useless --> sonarcloud[bot] removed a comment on

pull

request

Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc

[Olivier Heintz]

Thanks Jacques for the clarification,

But, I'm not sure to understand,
currently, doc is generated only for R17 and are only included in buildbot job 
for trunkFrameworkPlugin  ?
Work to do is to add for job R17Framework and R18Framework ?
Infra help is needed to publish for multi-release ?

can I help about one of these points ?

Olivier

Le 20/05/2020 à 17:15, Jacques Le Roux a écrit :
> Thanks Olivier,
> 
> I must add that it's the current location and it would need more work to 
> change it, notably Infra help
> 
> Jacques
> 
> Le 20/05/2020 à 16:24, Olivier Heintz a écrit :
>> Yes, of course
>>
>> My explanation was not clear, I propose to have one documentation by release 
>> and use it in the relative help
>>
>> My question is more about using (or not) 
>> ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc
>>
>> Le 20/05/2020 à 08:32, Michael Brohl a écrit :
>>> Hi Olivier,
>>>
>>> wouldn't it be better to have different documentation paths for the
>>> different branches?
>>>
>>> If we would show the trunk documentation/help for stable branches, it
>>> will most likely be wrong in some cases.
>>>
>>> Another thought: it would be great if we could have the docs available
>>> at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.
>>>
>>> Thanks,
>>>
>>> Michael Brohl
>>>
>>> ecomify GmbH - www.ecomify.de
>>>
>>>
>>> Am 19.05.20 um 11:54 schrieb Olivier Heintz:
 Hi Community,

 I need some comment or thought about one of point of the solution proposed.

 Is there some people against the fact of used 
 ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for 
 the ofbiz help ?

 As I explained in my previous email, 
 ci.apache.org/projects/ofbiz/site/ofbizdoc would be the default value for 
 userDocUri, (but value in
 general.properties can be change with the local place of doc generation).

 If community think, it's a good step solution (on the road to the new help 
 system), I will create a JIRA for generating the doc on all supported
 branches (currently, it's only done for r17)

 I just finished to migrate AccountingHelpData.xml to added the >>> field="helpAnchor" to the correct screens, so now it's really possible to 
 see if
 it's usable. I will updated the JIRA 11693.

 Olivier

 Le 12/05/2020 à 16:42, Olivier Heintz a écrit :
> Jira 11693 created with a patch proposed
>
> if this solution is accepted, (and all asciidoc integrated) next step is 
> to work component by component
> For each:
> 1. add in the component decorator  Title in user-documentation
> 2. using heldata.xml to update all screens which had a dedicated text for 
> help, with the new helpAnchor value
>
> It's not a too large task, which can be maybe add in the task list for 
> the next community days, and so finish the migration from docbook to 
> asciidoc ;-)
>
> any thoughts?
>
> ps: this week, I will do this job for accounting component
>
> Le 11/05/2020 à 15:38, Olivier Heintz a écrit :
>> Hi community,
>>
>> First step about Docbook migration to asciidoc is done, all existing 
>> files have been converted
>> (waiting a review before PR merge)
>>
>> Next step is to have a new help system,
>>
>> I propose to do a very simple solution which would be a link to a 
>> documentation site.
>> This solution would use
>> 1. at ofbiz level, a default proprety for documentation website uri
>> 2. at the screen level
>>   * it would be possible to give a other uri (for user documentation)
>>   * if the anchor in the user documentation for this screen is put, 
>> the new help is used otherwise the older link is used
>>
>> If this solution is validated, next step will be to update all the 
>> screens with the correct link value
>>
>> I propose to create the Jira (and the implmentation) with this very 
>> simple solution (using the doc generated by Buildbot as documentation 
>> site)
>> when some other people with a good knowledge of gradle and/or ofbiz cms 
>> have time to do a internal documentation website, it will be possible to
>> change the default uri ;-)
>>
>> what's your opinion about ?
>>
>>
>> Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
>>> inline
>>>
>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
 Hello Olivier,

 Without digging into much detail, I can say that it's a good idea to
 switch the online help system to asciidoc.

 The current structure of asciidoc templates is designed to be a full
 manual document. To link up different pages to different sections, you
 need to break the documentation down to smaller files and then combine
 them. This way you can have both the "big" manual and the "per 

Re: EntityBatchIterator for large data set queries

[Pritam Kute]

Hello Pawan,

I just had a look into the EntityQuery.queryIterator() method and looks
like we can achieve that by using fetchSize(), fowardOnly(),
cursorScrollInsensitive(), cursorScrollSensitive() and offset() methods in
EntityQuery class. Let me know if I am missing anything.

It will be good if you can post a pseudo code or something here so that we
could get an understanding of the exact design which you have in your mind.

Kind Regards,
--
Pritam Kute


On Thu, May 21, 2020 at 7:41 PM Pawan Verma 
wrote:

> Hello Devs,
>
> While working on the large database we have figured out that very large
> queries consume all memory and crash ofbiz(because queryIterator() doesn't
> really work, it's no different from queryList())
>
> The EntityListIterator attempts to use a cursor to iterate over large
> result sets but in reality most databases do not give us a cursor unless we
> ask for it in a very specific way, and instead you get back the full result
> set and potentially consume a large amount of memory.  For example, the
> MySql details are here (ResultSet section):
>
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html
>
> To work around this we've built the EntityBatchIterator which instead
> basically just pages through results like you would do on a webpage that
> uses pagination.  The iterator takes an EntityQuery and when next() is
> called it grabs the first 500 records and returns the first record, call
> next again and you get the second record, once you've called next 500 times
> it runs the query again with an offset and grabs the next 500 and so on
> until there are no more records.
>
> The main downsides to this approach are:
> 1. Same as when using limit/offset you want to be sure your results will
> come back in a consistent order to avoid accidentally skipping some rows
> and seeing other rows twice.
> 2. Because the results are a combination of many queries rather than a
> single query, some of the data may change while you are paging through it.
> i.e. if you were to sort by lastUpdatedTxStamp you may see some rows twice
> as they are updated by other transactions (this might be a good thing in
> some cases).
>
> So, the main proposal is to introduce a new EntityBatchIterator for large
> queries.  If we agree on the proposal I'll create a Jira and provide a
> patch for the community review. Thanks!
>
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>

Re: buildbot exception in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

FYI: I cloned INFRA-20297 at https://issues.apache.org/jira/browse/INFRA-20303 
for that

Le 23/05/2020 à 07:40, build...@apache.org a écrit :

The Buildbot has detected a build exception on builder 
ofbizTrunkFrameworkPlugins while building ofbiz-plugins. Full details are 
available at:
 https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1393

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf945_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
Build Source Stamp: [branch trunk] ade15ec80a6b241ad2e92ba89ab6bf88f9fde8cf
Blamelist: Suraj Khurana 

BUILD FAILED: exception upload_2

Sincerely,
  -The Buildbot

Re: @deprecated No replacement

[Pierre Smits]

+1 forellen removing refs

Op za 23 mei 2020 08:27 schreef Devanshu Vyas :

> +1 to remove references.
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Sat, May 23, 2020 at 11:54 AM Mridul Pathak <
> mridul.pat...@hotwaxsystems.com> wrote:
>
> > +1 to remove references.
> >
> > Thanks.
> > --
> > Mridul Pathak
> >
> >
> > > On 22-May-2020, at 1:03 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> > >
> > > Hi,
> > >
> > > We have 5, 8 years old, , "@deprecated No replacement" references in
> > Java code:
> > >
> https://ofbiz.markmail.org/search/?q=%22%40deprecated+No+replacement%22
> > >
> > > It seems they are all related to Minilang.  I think we should either
> > remove the concerned methods.
> > >
> > > Or rather, easier, remove the "@deprecated No replacement" references
> > since anyway Minilang is deprecated as a whole.
> > >
> > > I'm for the later and will do so in a week if nobody is against.
> > >
> > > Jacques
> > >
> >
> >
>

Re: @deprecated No replacement

[Devanshu Vyas]

+1 to remove references.

Thanks & Regards,
Devanshu Vyas.


On Sat, May 23, 2020 at 11:54 AM Mridul Pathak <
mridul.pat...@hotwaxsystems.com> wrote:

> +1 to remove references.
>
> Thanks.
> --
> Mridul Pathak
>
>
> > On 22-May-2020, at 1:03 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> >
> > Hi,
> >
> > We have 5, 8 years old, , "@deprecated No replacement" references in
> Java code:
> > https://ofbiz.markmail.org/search/?q=%22%40deprecated+No+replacement%22
> >
> > It seems they are all related to Minilang.  I think we should either
> remove the concerned methods.
> >
> > Or rather, easier, remove the "@deprecated No replacement" references
> since anyway Minilang is deprecated as a whole.
> >
> > I'm for the later and will do so in a week if nobody is against.
> >
> > Jacques
> >
>
>

Re: @deprecated No replacement

[Mridul Pathak]

+1 to remove references.

Thanks.
--
Mridul Pathak


> On 22-May-2020, at 1:03 PM, Jacques Le Roux  
> wrote:
> 
> Hi,
> 
> We have 5, 8 years old, , "@deprecated No replacement" references in Java 
> code:
> https://ofbiz.markmail.org/search/?q=%22%40deprecated+No+replacement%22
> 
> It seems they are all related to Minilang.  I think we should either remove 
> the concerned methods.
> 
> Or rather, easier, remove the "@deprecated No replacement" references since 
> anyway Minilang is deprecated as a whole.
> 
> I'm for the later and will do so in a week if nobody is against.
> 
> Jacques
> 

Re: Modify OFBiz commit message template

[Mridul Pathak]

+1

Thanks.
--
Mridul Pathak


> On 20-May-2020, at 2:31 PM, Jacques Le Roux  
> wrote:
> 
> Hi,
> 
> With Git IMO it's convenient (more information) to have the Jira number in 
> the title, eg: https://markmail.org/message/cyslglyoh5gf7l7t
> 
> If nobody disagree I'd like to modify
> 
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template
> 
> We could have
> 
> 
> 
> [Implemented | Improved | Fixed | Completed| Documented | Reverted]: [Jira 
> title | Free text] [(OFBIZ-)]
> 
> [(OFBIZ-)]
> 
> [More detailed explanation of what has been done and what the fix achieves,
> sideeffects etc.]
> 
> [Thanks:] [ for ... and  for]
> 
> 
> 
> But I would prefer:
> 
> [Implemented | Improved | Fixed | Completed| Documented | Reverted]: [Jira 
> title | Free text] [(OFBIZ-)]
> 
> [More detailed explanation of what has been done and what the fix achieves,
> sideeffects etc.]
> 
> [Thanks:] [ for ... and  for]
> 
> 
> Opinions?
> 
> Thanks
> 
> Jacques
>