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
