On Wed, May 20, 2009 at 5:19 PM, Stefano Bagnara <apa...@bago.org> wrote: > Robert Burrell Donkin ha scritto:
<snip> >>>>> The only real features for end users in that roadmap is jSPF and this >>>>> could be released as a mailet anyway. jSPF as it is in trunk cannot be >>>>> done in v2.3 because of different fastfail stuff (IIRC). >>>> fine - so let's factor out an SMTP library as well (multi-module with >>>> avalon and OSGi service bindings) >>>> >>>> this means a DNS service library as well but IMHO that's a good thing. >>>> UserRepository is a little too much to chew ATM but i think we should >>>> be able to bridge the interfaces. >>>> >>>> AIUI this'd give us improved fail fast as well >>> This is trunk, isn't it? >>> If you take v2.3 and replace smtp, userrepositories, dnsservice and >>> every dependency that need changes because of this (most components >>> depend on dnsservice) then you have trunk (just with less modules: take >>> a revision from 1 year ago and you'll have v2.3 with that stuff and no >>> modules ;-) ). >> >> not really >> >> it doesn't include IMAP or any of the other code that would need to be >> reviewed and tested to release 3.0, just the new features which users >> seem to want. factoring them into libraries means that any heated >> debates about design can happen in isolated not as part of a bigger >> quality argument about 3.x verses 2.x. > > Do you really think IMAP is the issue? trunk is modular, it is easy to > release it without IMAP (but I don't think this is the real issue). IMAP isn't a problem: it's in a separate library. it's the rest of the code. danny and noel are absolutely right that no one understands 75% of the code base (by volume) any more i don't run most of the services, and they've been broken for long periods over the last few years i'd be happier taking a step based approach: factoring out a library, diffing with 2.x to understand any differences then separating out API and avalon modules. i have an incentive to do this since i could then add OSGi service bindings to each library (these are nice but not necessary for karaf). >> (maybe you're starting to understand the plan now ;-) > > No, we discussed this at least twice in past, and I didn't change my > mind. Looking at v2.3 is waste. Trunk is not anything revolutionary. It > include really *MINOR* changes and they are in trunk only because they > break some interface or compatibility. unless you change your mind or figure out some other way forward, then james server will die i was hopeful that a 3.x would be possible but we're too short of testers and documentors a gradualist approach would mean that 2.x users could contribute to testing and documentation - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org