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" > > 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 [...] -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
