Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Mathieu Lirzin]

Hello Suraj,

Suraj Khurana  writes:

> Interestingly, I checked and got fail in a case when I have plugins as well
> in the directory structure.
>
> I am using this command to check single test:
> ./gradlew "ofbiz --test component=order --test suitename=ordertests --test
> case=order-tests"

It will not work because the “order-tests” test case implicitly depends
on the “order-tests-data-load” (yes it sucks...).  So you need to run
the whole test suite:

  ./gradlew "ofbiz --test component=order --test suitename=ordertests"

> It works fine when I run ./gradlew testIntegration. On a cursory view, IMO,
> data is also not dependent anywhere in the plugins directory, so this
> should not be the case.
>
> I will have a deeper look into it and provide more details soon (probably
> during the weekend).

I have been looking at this issue this evening, and after some hours I
still do not understand the bug.  It is depressing to see how hard it is
to work with OFBiz integration tests.

If you don't find a solution before the end of the week, please revert
revision 1856596 which introduces the issue (meaning removing
“OrderTests.groovy”).

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [OPTIONS] Java 11 and Java JDK origin

[Jacques Le Roux]

Ah OK

Le 19/04/2019 à 21:16, Taher Alkhateeb a écrit :

It's already done. I'm suggesting future actions for future JDKs

On Fri, Apr 19, 2019, 8:53 PM Jacques Le Roux 
wrote:


Hi Taher,

Sounds like a plan, will you create those Jiras Taher?

Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it
until we swap?

I believe the later is the easiest for all of us, but could be confusing
after a moment.

Jacques

Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :

I see no problem in sticking with 8. It would also probably be
beneficial to get the code base to be compatible with Java 11 so that
people who want to upgrade are not restricted from doing so (which we
have done already). In other words, like Scott said, it should be a
"minimum" instead of a "maximum". When we were trying to upgrade we
faced some obstacles and resolved them. which means this needs to be a
task regularly done.

So we could perhaps regularly create JIRAs like "Ensure OFBiz can
operate on Java version X" so that the code base is always forward
compatible.

On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
 wrote:

Reasons to increase the minimum version:
- compelling new features
- end of support of current minimum

Reasons to not increase the minimum:
- potential instability of new version
- complicates the life of users and contributors who still use the

existing

minimum
- lack of expertise in configuring and using new features

I think every few months we should discuss it but I don't think it's

worth

shifting any time soon. The pros need to outweigh the cons, and

personally

I don't really see it at the moment.

The end of support date for 11 probably shouldn't be a consideration at
this point, by the time we even get close to that java 23 LTS will

probably

be a year old :)

Regards
Scott

On Tue, 16 Apr 2019, 00:50 Michael Brohl, 

wrote:

Ah, sorry Taher if I was not clear enough.

Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
trunk, 18.12 and 17.12 to make the project independent from the short
cycled releases of the Oracle JDK and the subscription for use of the
Oracle JDK 8 LTS.

I just recognized that Adopt JDK 11 LTS will be available until Sept.
2022. If that is not a mistake I have to refine the timeline: we can
then switch to Adopt Open JDK 11 LTS on trunk right before the release
branch for 19.x is created. I guess that the future LTS releases will
have support for at least 4 years.

That means we would remain Java 8 compatible for the releases 16 to 18
and announce the Java 11 dependency for release 19 and up. This should
give users enough time to plan, test and migrate.

Users could work with release branch 19.x on Open JDK 11 for 2,5 years
then.

For the future, I would suggest to introduce a new Open JDK LTS version
about 3-6 months after the first release, we might want to create a new
release branch in the course of this.

What do you think?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:

Hi Michael,

So just to understand your suggestion clearly. Are you recommending
that we switch from oracle JDK to open JDK now (in 18 and trunk) and
introduce open jdk 11 in 2021?

On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl <

michael.br...@ecomify.de>

wrote:

Hi Scott, all,

yes, Adopt Open JDK 8 LTS is supported at least untile September 2023

[1]

Thinking about this a bit more I second to stay with Open JDK 8 LTS

for

release branches 17.12, 18.12 and trunk for now.

Professional users/ companies have a very conservative update

strategy

for base technologies like the JDK and we should support it as long

as

it is reasonable.

So, my suggestion would be to introduce Adopt Open JDK 11 LTS with

the

release branch 21.x, meaning that we change to JDK 11 right before

the

release branch will be created. This gives us plenty of time to test
with Java 11 and we can introduce Java 11 features in the trunk after
that. So release branch 22.x would be the first to depend on Java 11.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] https://adoptopenjdk.net/support.html


Am 15.04.19 um 00:07 schrieb Scott Gray:

My understanding was that openjdk would support java 8 until 2023.

In the past our strategy used to be that we should ensure the code

base

would operate on newer java versions but keep our minimum required

version

as low as possible.  That effectively allows users to run whatever

version

they like.  So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our

minimum

supported version as low as possible.

For myself, all client projects are still running java 8 (openjdk)

so

before I could continue contributing to OFBiz I would have to figure

out

how to run both versions on my machine with minimal disruption.

Since

I

don't have a huge amount of spare time, I would probably just put it

off

for quite a while 

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

It's already done. I'm suggesting future actions for future JDKs

On Fri, Apr 19, 2019, 8:53 PM Jacques Le Roux 
wrote:

> Hi Taher,
>
> Sounds like a plan, will you create those Jiras Taher?
>
> Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it
> until we swap?
>
> I believe the later is the easiest for all of us, but could be confusing
> after a moment.
>
> Jacques
>
> Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :
> > I see no problem in sticking with 8. It would also probably be
> > beneficial to get the code base to be compatible with Java 11 so that
> > people who want to upgrade are not restricted from doing so (which we
> > have done already). In other words, like Scott said, it should be a
> > "minimum" instead of a "maximum". When we were trying to upgrade we
> > faced some obstacles and resolved them. which means this needs to be a
> > task regularly done.
> >
> > So we could perhaps regularly create JIRAs like "Ensure OFBiz can
> > operate on Java version X" so that the code base is always forward
> > compatible.
> >
> > On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
> >  wrote:
> >> Reasons to increase the minimum version:
> >> - compelling new features
> >> - end of support of current minimum
> >>
> >> Reasons to not increase the minimum:
> >> - potential instability of new version
> >> - complicates the life of users and contributors who still use the
> existing
> >> minimum
> >> - lack of expertise in configuring and using new features
> >>
> >> I think every few months we should discuss it but I don't think it's
> worth
> >> shifting any time soon. The pros need to outweigh the cons, and
> personally
> >> I don't really see it at the moment.
> >>
> >> The end of support date for 11 probably shouldn't be a consideration at
> >> this point, by the time we even get close to that java 23 LTS will
> probably
> >> be a year old :)
> >>
> >> Regards
> >> Scott
> >>
> >> On Tue, 16 Apr 2019, 00:50 Michael Brohl, 
> wrote:
> >>
> >>> Ah, sorry Taher if I was not clear enough.
> >>>
> >>> Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> >>> trunk, 18.12 and 17.12 to make the project independent from the short
> >>> cycled releases of the Oracle JDK and the subscription for use of the
> >>> Oracle JDK 8 LTS.
> >>>
> >>> I just recognized that Adopt JDK 11 LTS will be available until Sept.
> >>> 2022. If that is not a mistake I have to refine the timeline: we can
> >>> then switch to Adopt Open JDK 11 LTS on trunk right before the release
> >>> branch for 19.x is created. I guess that the future LTS releases will
> >>> have support for at least 4 years.
> >>>
> >>> That means we would remain Java 8 compatible for the releases 16 to 18
> >>> and announce the Java 11 dependency for release 19 and up. This should
> >>> give users enough time to plan, test and migrate.
> >>>
> >>> Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> >>> then.
> >>>
> >>> For the future, I would suggest to introduce a new Open JDK LTS version
> >>> about 3-6 months after the first release, we might want to create a new
> >>> release branch in the course of this.
> >>>
> >>> What do you think?
> >>>
> >>> Regards,
> >>>
> >>> Michael Brohl
> >>>
> >>> ecomify GmbH - www.ecomify.de
> >>>
> >>>
> >>> Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
>  Hi Michael,
> 
>  So just to understand your suggestion clearly. Are you recommending
>  that we switch from oracle JDK to open JDK now (in 18 and trunk) and
>  introduce open jdk 11 in 2021?
> 
>  On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl <
> michael.br...@ecomify.de>
> >>> wrote:
> > Hi Scott, all,
> >
> > yes, Adopt Open JDK 8 LTS is supported at least untile September 2023
> >>> [1]
> > Thinking about this a bit more I second to stay with Open JDK 8 LTS
> for
> > release branches 17.12, 18.12 and trunk for now.
> >
> > Professional users/ companies have a very conservative update
> strategy
> > for base technologies like the JDK and we should support it as long
> as
> > it is reasonable.
> >
> > So, my suggestion would be to introduce Adopt Open JDK 11 LTS with
> the
> > release branch 21.x, meaning that we change to JDK 11 right before
> the
> > release branch will be created. This gives us plenty of time to test
> > with Java 11 and we can introduce Java 11 features in the trunk after
> > that. So release branch 22.x would be the first to depend on Java 11.
> >
> > What do you think?
> >
> > Best regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > [1] https://adoptopenjdk.net/support.html
> >
> >
> > Am 15.04.19 um 00:07 schrieb Scott Gray:
> >> My understanding was that openjdk would support java 8 until 2023.
> >>
> >> In the past our strategy used to be that we should ensure the code
> base
> >> would operate on newer 

Re: [OPTIONS] Java 11 and Java JDK origin

[Jacques Le Roux]

Hi Taher,

Sounds like a plan, will you create those Jiras Taher?

Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it until we 
swap?

I believe the later is the easiest for all of us, but could be confusing after 
a moment.

Jacques

Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :

I see no problem in sticking with 8. It would also probably be
beneficial to get the code base to be compatible with Java 11 so that
people who want to upgrade are not restricted from doing so (which we
have done already). In other words, like Scott said, it should be a
"minimum" instead of a "maximum". When we were trying to upgrade we
faced some obstacles and resolved them. which means this needs to be a
task regularly done.

So we could perhaps regularly create JIRAs like "Ensure OFBiz can
operate on Java version X" so that the code base is always forward
compatible.

On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
 wrote:

Reasons to increase the minimum version:
- compelling new features
- end of support of current minimum

Reasons to not increase the minimum:
- potential instability of new version
- complicates the life of users and contributors who still use the existing
minimum
- lack of expertise in configuring and using new features

I think every few months we should discuss it but I don't think it's worth
shifting any time soon. The pros need to outweigh the cons, and personally
I don't really see it at the moment.

The end of support date for 11 probably shouldn't be a consideration at
this point, by the time we even get close to that java 23 LTS will probably
be a year old :)

Regards
Scott

On Tue, 16 Apr 2019, 00:50 Michael Brohl,  wrote:


Ah, sorry Taher if I was not clear enough.

Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
trunk, 18.12 and 17.12 to make the project independent from the short
cycled releases of the Oracle JDK and the subscription for use of the
Oracle JDK 8 LTS.

I just recognized that Adopt JDK 11 LTS will be available until Sept.
2022. If that is not a mistake I have to refine the timeline: we can
then switch to Adopt Open JDK 11 LTS on trunk right before the release
branch for 19.x is created. I guess that the future LTS releases will
have support for at least 4 years.

That means we would remain Java 8 compatible for the releases 16 to 18
and announce the Java 11 dependency for release 19 and up. This should
give users enough time to plan, test and migrate.

Users could work with release branch 19.x on Open JDK 11 for 2,5 years
then.

For the future, I would suggest to introduce a new Open JDK LTS version
about 3-6 months after the first release, we might want to create a new
release branch in the course of this.

What do you think?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:

Hi Michael,

So just to understand your suggestion clearly. Are you recommending
that we switch from oracle JDK to open JDK now (in 18 and trunk) and
introduce open jdk 11 in 2021?

On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl 

wrote:

Hi Scott, all,

yes, Adopt Open JDK 8 LTS is supported at least untile September 2023

[1]

Thinking about this a bit more I second to stay with Open JDK 8 LTS for
release branches 17.12, 18.12 and trunk for now.

Professional users/ companies have a very conservative update strategy
for base technologies like the JDK and we should support it as long as
it is reasonable.

So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the
release branch 21.x, meaning that we change to JDK 11 right before the
release branch will be created. This gives us plenty of time to test
with Java 11 and we can introduce Java 11 features in the trunk after
that. So release branch 22.x would be the first to depend on Java 11.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] https://adoptopenjdk.net/support.html


Am 15.04.19 um 00:07 schrieb Scott Gray:

My understanding was that openjdk would support java 8 until 2023.

In the past our strategy used to be that we should ensure the code base
would operate on newer java versions but keep our minimum required

version

as low as possible.  That effectively allows users to run whatever

version

they like.  So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our

minimum

supported version as low as possible.

For myself, all client projects are still running java 8 (openjdk) so
before I could continue contributing to OFBiz I would have to figure

out

how to run both versions on my machine with minimal disruption.  Since

I

don't have a huge amount of spare time, I would probably just put it

off

for quite a while and work on other things.

I'm not trying to veto the idea, if the community wants to proceed

then it

should but I doubt I'm the only contributor we'd be putting another

hurdle

in front of.

Regards
Scott

On Mon, 15 Apr 

Re: [PROPOSAL] Enable entity timestamp fields

[Jacques Le Roux]

Hi Pawan,

Seems to make sense, do you know when (by which commit) it has been removed. 
Was it intentional? If yes what was the reason?

Thanks

Jacques

Le 19/04/2019 à 18:03, Pawan Verma a écrit :

Hello  Devs,

While working on a Production environment, I have found that for some
reason entity timestamp fields are disabled at Search Results screen in
Trunk and the previous release branch. It is available at View Value
screen. It was enabled in Release 16.11.

These fields are helpful for developers to get the idea about when the row
in the entity is created/updated. Extremely helpful while working on the
Production environment.

I propose to reenable these fields. Views/suggestions are most welcome.

[PROPOSAL] Enable entity timestamp fields

[Pawan Verma]

Hello  Devs,

While working on a Production environment, I have found that for some
reason entity timestamp fields are disabled at Search Results screen in
Trunk and the previous release branch. It is available at View Value
screen. It was enabled in Release 16.11.

These fields are helpful for developers to get the idea about when the row
in the entity is created/updated. Extremely helpful while working on the
Production environment.

I propose to reenable these fields. Views/suggestions are most welcome.

-- 
Kind Regards,
*Pawan Verma* | Technical Consultant
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P. 452010
Linkedin: *Pawan Verma *