Re-designing the ‘Security’ interface

[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

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

[Kev2600]

unsubscribe

On Fri, May 10, 2019, 12:53 PM Mathieu Lirzin, <[hidden email]>
wrote:

> 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
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

[Michael Brohl-3]

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
>

[Jacques Le Roux]

Hi Michael,

Thanks for mentioning this which came already on the table several times.

We had this discussion in the past[1] (the last one?). But AFAIK only about services and came to this agreement[2]

[1] https://markmail.org/message/gqultbcgbonph5ax

[2] https://s.apache.org/12Uq

I don't remember if we took a decision about how handling Java code.

Your proposition for Java seems the same idea but with longer time. Quoting Nicolas

    <<We tag code deprecated as a part of a release and these code will be removed from next release.>>

Please review [2], a consensus would be needed about 1 or 2 releases before removing from code. I expect the same rule for all the code (services or
what not).

 From my side I see no urge to remove and 2 releases after deprecation fits with me, ie your proposition here.

Beside generalising, we maybe need to state a clearer rule at [2]...

Thanks

Jacques


Le 11/05/2019 à 09:48, Michael Brohl a écrit :

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