Re: Re-designing the ‘Security’ interface
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 <> 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
Re: Re-designing the ‘Security’ interface
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
Re: Re-designing the ‘Security’ interface
unsubscribe On Fri, May 10, 2019, 12:53 PM Mathieu Lirzin, 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 >
