My bad, answer inlined... On 13/11/2019 15:24, Matthieu Baechler wrote: > Hi Benoit, > > It looks like you forgot the answer to the mailing list. > > On Wed, 2019-11-13 at 14:46 +0700, Tellier Benoit wrote: >> Hi Matthieu >> >> On 12/11/2019 15:19, Matthieu Baechler wrote: >>> Hi Benoit, >>> >>> On Mon, 2019-11-11 at 14:36 +0700, Tellier Benoit wrote: >>>> [...] >>>> >>>> I propose the following removals in 3.5.0: >>>> >>>> - mailet/api MailAddress (unused , deprecated in 2017 see JAMES- >>>> 2138) >>>> - protocols/smtp MailAddress (unused , deprecated in 2017 see >>>> JAMES- >>>> 2138) >>> >>> Are you sure about the JIRA number? >> >> Sure, that's the commit message prefix used for marking deprecation. > > Here https://issues.apache.org/jira/browse/JAMES-2138 the issue title > is: "Implement Groups WebAdmin API" >
A git blame in protocols/smtp/src/main/java/org/apache/james/protocols/smtp/MailAddress.java Reports: JAMES-2138 move MailAddress to a new james-core project move james.core package to james.server.core to avoid conflict Author: Matthieu Baechler Date:04/09/2017 I'm very glad that in two years we achieved a better issue splitting. >>> Also, what's wrong about having several instances of a given >>> concept? >>> >>> I mean, do you want James core code to be unable to change the >>> MailAddress public API because it would break API stability for >>> users? >>> >>> Using the same object everywhere means you introduce coupling and >>> coupling is not always a good thing. >>> >>> Could you elaborate why you think coupling protocols/smtp, >>> mailet/api >>> and james/core is a good thing? (pros/cons) >> >> Coupling protocols/smtp, mailet/api and james/core are already >> coupled >> as mailet/api & protocols/smtp extends james/core MailAddress. > > The fact we did something in the past doesn't mean we can't undo it > now. > >> I take backward compatibility argument for keeping using >> "MailAddress" >> in user implemented extensions. >> >>>> [...] >>>> >>>> As such, I propose to deprecate in 3.5.0, targeting a removal in >>>> 3.6.0 >>>> the followings: >>>> >>>> - james-server-mailet BayesianAnalysis + BayesianAnalysisFeeder >>>> + >>>> JDBCBayesianAnalyzer. >>>> mailet/ai mailets to be used instead. >>> >>> Did you evaluate each package? What is the rational to choose one >>> rather than the other? >> >> After digging on the mailing list archives: >> >> - James server code regarding this dates from 2006. >> - Mailet AI module inception dates 2011. >> >> The code is very similar and moistly duplicated. Thus keeping the >> most >> recent and maintained version sounds legitimate. > > +1 > > [...] > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
