And now the bulk questions:
A. Deprecate phoenix
+0.8
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.8
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
+0.8
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.8
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.2
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
+0.2
E2. Use JNDI to lookup users/mail repositories, the store and any
other James component.
+0.2
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.5 for a proper subset (which one :-) ?)
-0.8 for everything
E4. Use Dependency Injection (setter based, constructor based,
enabling interfaces, service locator injection) to automatically
satisfy components dependencies.
+0
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
+0
G1. Use CDI (constructor base DI)
G2. Use Setters
G3. Use Setters with Enabling Interfaces
G4. Keep single setter for ServiceLocator (ala Avalon)
G5. Use reflection and convention over configurations for the above DI
Furthermore these technologies could be used to sole one or more
aspects of the above points, please give your opinions.
H1. Use Spring
+0
H2. Use XBean
+0
H3. Use OSGi Declarative Services
+0
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
