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

2019-05-11 Thread Suraj Khurana 
Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana 
wrote:

> Sure Jacques,
>
> I will get this done by the weekend. Please proceed in case of any blocker
> or urgency. I am also inclined with your thoughts.
> Thanks in advance !!
>
> --
> Best Regards,
> Suraj Khurana
> Technical Consultant
>
> *HotWax Systems Pvt. Ltd*
>
>
>
>
>
> On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi Suraj,
>>
>> Any chances? I don't mind duplicated data as I mentioned answering to
>> Pierre
>>
>> Thanks
>>
>> Jacques
>>
>> Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :
>> > Thanks Suraj,
>> >
>> > Can't we avoid the duplicated data?
>> >
>> > Jacques
>> >
>> > Le 27/04/2019 à 15:17, Suraj Khurana a écrit :
>> >> Hello team,
>> >>
>> >> I have checked and found that there is a data dependency of
>> >> workEffortId=9000 in the test case which is available in
>> plugins/projectmgr
>> >> component.
>> >>
>> >> This was the main reason testIntegration was failing without having
>> plugins
>> >> component. I will take care of it and add respective dependent data on
>> >> order test data file.
>> >>
>> >> I think its making sense now and we don't need to revert now.
>> >>
>> >> --
>> >> Best Regards,
>> >> Suraj Khurana
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana <
>> suraj.khur...@hotwax.co>
>> >> wrote:
>> >>
>> >>> Sure Jacques,
>> >>>
>> >>> I am into it today and if got nothing I will remove OrderTests.groovy
>> >>>
>> >>> --
>> >>> Best Regards,
>> >>> Suraj Khurana
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
>> >>> jacques.le.r...@les7arts.com> wrote:
>> >>>
>>  Hi Suraj,
>> 
>>  I think that, as suggested by Mathieu, in the meantime it's better to
>>  remove “OrderTests.groovy”
>> 
>>  Because it could hide other issues else reported by Buildbot which
>> is our
>>  last safeguard
>> 
>>  Thanks
>> 
>>  Jacques
>> 
>>  Le 25/04/2019 à 10:52, Pierre Smits a écrit :
>> > Hi Mathieu,
>> >
>> > Is there a way to move this forward?
>> >
>> > Best regards,
>> >
>> > Pierre Smits
>> >
>> > *Apache Trafodion , Vice President*
>> > *Apache Directory , PMC Member*
>> > Apache Incubator , committer
>> > *Apache OFBiz , contributor (without
>>  privileges)
>> > since 2008*
>> > Apache Steve , committer
>> >
>> >
>> > On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits <
>> pierresm...@apache.org>
>>  wrote:
>> >> Maybe we should move the load aspects regarding tests out of the
>> test
>> >> suite invocations altogether.
>> >> The gradlew tasks states:
>> >>
>> >> task testIntegration(group: ofbizServer) {
>> >>
>> >> dependsOn 'ofbiz --test'
>> >>
>> >> description 'Run OFBiz integration tests; You must run loadAll
>> before
>> >> running this task'
>> >>
>> >> }
>> >>
>> >>
>> >> IMO, loading test data could be part of the loadAll task.
>> >>
>> >>
>> >> Best regards,
>> >>
>> >> Pierre Smits
>> >>
>> >> *Apache Trafodion , Vice President*
>> >> *Apache Directory , PMC Member*
>> >> Apache Incubator , committer
>> >> *Apache OFBiz , contributor (without
>>  privileges)
>> >> since 2008*
>> >> Apache Steve , committer
>> >>
>> >>
>> >> On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin <
>>  mathieu.lir...@nereide.fr>
>> >> wrote:
>> >>
>> >>> Pierre Smits  writes:
>> >>>
>>  I believe there are a few more where testing individual
>> test-suites
>> >>> and/or
>>  test-cases are dependent on data loaded in other test-suites
>> and/or
>> >>> other
>>  test-cases.
>> >>> I have the same experience.  Moreover another source of fragility
>> is
>> >>> that tests depend on other tests within a single OFBiz
>> “test-case”,
>> >>> meaning one test can depend on the data produced by another test.
>>  This
>> >>> is acceptable for a “simple-method-test” because the order of
>>  execution
>> >>> is sequential and managed by OFBiz, but this is problematic for
>> JUnit
>> >>> tests (Groovy, Java) because the order while being deterministic
>>  depends
>> >>> on the arbitrary order imposed by the JVM.
>> >>>
>> >>> For example I know for a fact that “QuoteTests.groovy” is
>> suffering
>>  from
>> >>> that issue.
>> >>>
>>  While I don't hear/read about failing testIntegration (except

Re: Re-designing the ‘Security’ interface

2019-05-11 Thread Michael Brohl 

Hi Mathieau,

We had a discussion about deprecation in the past, I currently do not 
have the time to dig it out.


I think we should start annotating  @deprecated with the date/release 
branch when it was introduced. User should have at least time over 2 
releases to move from the old to the new implementation.


In this example, we would introduce the deprecation in trunk, so it will 
first be "visible" for users in release 19.x. We can then remove the 
deprecated code after the 20.x branch was created.


We should also start to track the deprecatations and consequently remove 
deprecated code when its time (see above). Currently there are some 
depretations for years, with no tags when they were introduced so we can 
get better at this.


Just wanted to throws this in for a first feedback, more later.

Thanks for your work!

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.05.19 um 17:53 schrieb Mathieu Lirzin:

Hello,

I have opened the ticket OFBIZ-11019 which deprecates a method in the
‘org.apache.ofbiz.security.Security’ interface (see rationale in the
JIRA ticket). If nobody disagree in the meantime, I will commit the
attached patch in a week.

With OFBIZ-11019, near half of the declarations of that interface are
now deprecated which is a symptom a poor initial design.  As a
consequence I think it is time to consider re-designing a new interface
to superseed ‘org.apache.ofbiz.security.Security’.

In order to achieve a better design, it would help if people currently
implementing ‘org.apache.ofbiz.security.Security’ outside of the
framework could describe their use-case and requirements.

If nobody step-up, It will consider that as a sign that this extension
mechanism might not be useful anymore and could be removed.

Thanks in advance.

[1] https://issues.apache.org/jira/browse/OFBIZ-11019





smime.p7s
Description: S/MIME Cryptographic Signature