Hi, Must say that I feel a little uncomfortable with this vote, as many of the issues IMO needs more discussion/investigation before calling a vote, but I will play along and vote.
Also there are issues I rather saw moving like: getting rid of JavaMail :-) On Thursday 13 July 2006 16:48, Stefano Bagnara wrote: > > And now the bulk questions: > > A. Deprecate phoenix +0.8 I do not like that we are based so heavily on unmaintained codebase. If we keep these we should make them part of the James codebase. > A1. Replace it with Plexus (http://plexus.codehaus.org/) -0 > A2. Replace it with another Avalon compliant container (name it) -0 > A3. Replace it with Felix (http://incubator.apache.org/felix/) +0.2 > > B. Remove avalon +0.8 > B1. Remove it from "API Components" +0.8 > B2. Remove it from both API Components and Other James Components +0.5 > B3. Remove it from all the codes and keep wrapper for Top Level > Components to be adapted to the container (Avalon or other). +0.5 > > C. Remove Cornerstone +0.8 > C1. Remove cornerstone dependencies in favor of Jakarta commons > libraries where available +0.8 > C2. Use MINA to replace sockets/connection dependencies +0.8 > C3. Import code from not replaceable libraries to James codebase > (refactoring it to remove Avalon and anything else needed) +0.8 > > Now I expect that many will have replied +X to A3 or at least to one of > the B*, so here are further votes related to this scenario. > > D. Lifecycle and dependency management > D1. Use JNDI everywhere (ala J2EE) -0 > D2. Keep Avalon interfaces but write our own mini container for non Top > Level Components. -0 > D3. Introduce new interfaces to replace the one from Avalon and create > our own container (that may delegate to the real container we use) to > manage lifecycle and dependencies. (see also "Central class for service > injection" topic by Bernd) -0.5 > > E. Specific API Components issues: > E1. Use JNDI to lookup datasources +0.5 > E2. Use JNDI to lookup users/mail repositories, the store and any other > James component. +0.5 > E3. Add datasource, repositories, store and any other used service to > the MailetContext API (this also mean adding the interfaces for this > objects to the Mailet APIs) -0.9 > E4. Use Dependency Injection (setter based, constructor based, enabling > interfaces, service locator injection) to automatically satisfy > components dependencies. +0.8 > E5. Keep the ServiceManager as a property stored in the MailetContext. -0.8 > > If you voted +X to something DI related please also vote this: > > G. Dependency Injection > G1. Use CDI (constructor base DI) -0 > G2. Use Setters +0.5 > G3. Use Setters with Enabling Interfaces +0.5 > G4. Keep single setter for ServiceLocator (ala Avalon) -0.8 > G5. Use reflection and convention over configurations for the above DI +0.5 > > Furthermore these technologies could be used to sole one or more aspects > of the above points, please give your opinions. > H1. Use Spring +0.5 (I really like Spring) > H2. Use XBean +0 > H3. Use OSGi Declarative Services -0 --Søren > > > Stefano > > PS: I'm willing to track this thread and produce an (i hope unbiased) > overview of the result. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
