Here is a summary of casted opinions.
Please note that I tried to resemble votes as -?/+? when there was a too
long description without a vote.
At a first glance I can say that we have found consensus on fewer issue
than I expected.
----------------
We all voted +? to this:
B1. Remove Avalon from API Components.
C. Remove Cornerstone
C1. Remove Cornerstone dependencies in favor of Jakarta Commons when
available
C2. Use MINA to *add* sockets/connection dependencies (Noel is against
the replace)
G2. Use Setters (as the preferred DI solution)
We all voted against this:
E5. Keep the ServiceManager as a property stored in the MailetContext.
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) [Note that Vincenzo is +0.5 on adding a
subset of this services]
About the container we all have no strong opinions: no vote under -0 has
been casted to A* questions.
The main problem is that about E5 and B1 we agreed on the goal but we
have very different views on how to do that. If we take the -1 as vetoes
then we have currently *no* accepted solution.
Here is a list of things where no votes under "-0" have been casted and
there is at least a "+1":
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
H3. Use OSGi Declarative Services
The remaining issues have contrasting answers (-1 .. +1).
I think that the experiment worked, and that this is a "better than
nothing" starting point to start specific discussions or specific
proposals having an overview of the mood of the team about each aspect.
Stefano
And here is the summary:
--------------
A. Deprecate phoenix
-0 Stefano (in the short term (an year))
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
+1 Noel - But in what timeframe? I am in no rush
+0.8 Søren - 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.
+0.8 Vincenzo
-1 Serge - See the comment in the message
A1. Replace it with Plexus (http://plexus.codehaus.org/)
+0 Stefano (Plexus seems to be actively developed (for maven2) and
supports avalon components and more (must be investigated))
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
-? Noel - As for your A1, A2, A3, the only one I like is A3, but
although that may be the right direction for JAMES, we have to
investigate it
-0 Soren
+0 Norman - Never used..
-0 Vincenzo
-0 Serge
A2. Replace it with another Avalon compliant container (name it)
-0 Stefano (After excluding Loom and having upgraded to the latest
Phoenix I don't see other plausible containers).
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
-? Noel - As for your A1, A2, A3, the only one I like is A3, but
although that may be the right direction for JAMES, we have to
investigate it
-0 Soren
-0 Norman
-0 Vincenzo
-0 Serge
A3. Replace it with Felix (http://incubator.apache.org/felix/)
-0 Stefano (in the short term because OSGi will increase the time to
become confortable with the application. +0.5 in the long term)
+0 Bernd - to A1-3, I don't favor any yet. As soon as our code becomes
'clean' this should be not a big deal for me.
+? Noel - As for your A1, A2, A3, the only one I like is A3, but
although that may be the right direction for JAMES, we have to
investigate it
+0.2 Soren
+0.5 Norman - Felix seems to be very intressting.. But maybe its a bit
overkill..
+0.2 Vincenzo
-0 Serge
B. Remove avalon
-0 Stefano - I feel good with Avalon, imho we can remove some of its
pattern (ServiceManager) and keep the basic interfaces.
+1 Bernd
+1 Noel - But again, there is a migration strategy
+0.8 Soren
+0.8 Vincenzo
+1 Serge - (ideal world)
B1. Remove it from "API Components"
+0.2 Stefano - if we introduce a james specific DI to supports this
components and add Lifecycle to the component API.
+1 Bernd
+0.8 Soren
+0.8 Norman - That whould be cool.. I don't like the idea of need
knowing about avalon to write mailets or smtphandler etc..
+0.8 Vincenzo
+1 Serge
B2. Remove it from both API Components and Other James Components
-0.5 Stefano - nonsense: I prefer B1 or B3.
+1 Bernd
+0.5 Soren
-0.5 Norman
+0.8 Vincenzo
+1 Serge
B3. Remove it from all the codes and keep wrapper for Top Level
Components to be adapted to the container (Avalon or other).
-0 Stefano
+1 Bernd
+? Noel - *EVENTUALLY*
+0.5 Soren
-0.5 Norman
+0.8 Vincenzo
+1 Serge
C. Remove Cornerstone
+0.2 Stefano - but I will vote each change library per library.
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+? Noel - Again, a process, not a cliff.
+0.8 Soren
+0.8 Vincenzo
+1 Serge
C1. Remove cornerstone dependencies in favor of Jakarta commons
libraries where available
+0.5 Stefano
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+1 Noel
+0.8 Soren
+0.5 Norman
+0.8 Vincenzo
+1 Serge
C2. Use MINA to replace sockets/connection dependencies
+1 Stefano - I don't have problem with java 1.5 requirement for James
3.0 and I think we should try to deprecate old code (less code to
mantain, less bugs)
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
-1 Noel - to replace.
+1 Noel - to ADD new MINA versions that will EVENTUALLY replace the
current ones. Solution to this problem already outlined.
+0.8 Soren
+1 Norman - After what i see on apacheCon this seems to be the best way
to get a better rid of many connections etc.
+0.8 Vincenzo
+0 Serge
C3. Import code from not replaceable libraries to James codebase
(refactoring it to remove Avalon and anything else needed)
-0 Stefano - I would do this only for Excalibur components (Avalon
specific) if we decide to remove Avalon from everywhere.
+1 Bernd - C1-C3, but I consider this to be a very long time project,
curretly more of the visionary type. I have many sympathies for starting
with MINA soon.
+? Noel - If necessary. What do you have in mind that is not replaceable?
+0.8 Soren
-0 Norman
+0.8 Vincenzo
-0 Serge
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)
-1 Stefano
-0 Bernd
+? Noel - Needs to be explored. Far too early to vote upon. For one
thing, despite how long it has been around, I suspect that few people
know enough about JNDI to cast an informed vote.
-0 Soren
+0 Norman - Can say anything about this.. no expirence
+0 Vincenzo
-1 Serge
D2. Keep Avalon interfaces but write our own mini container for non Top
Level Components.
+1 Stefano - I would keep Avalon lifecycle and logger. Eventually change
Configuration and ServiceManager in favor of a different COnfiguration
mechanism and DI for single services (remove Service Locator).
-0 Bernd
-1 Noel - -1 as a policy, not code.
-0 Soren
+0.5 Norman - I like avalon ;-)
-0.8 Vincenzo
-1 Serge
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 Stefano - If they have to be identical to Avalon interfaces I'd
keep Avalon ones.
+0 Bernd - (I see my proposal only as an intermediate step on the way to
reduce Avalon deps)
+? Noel - Containers. Plural. We need to distinguish which containers
we have, and what would be appropriate for each. And the answers to the
above questions may be different for the Mailet Container vs other
containers.
-0.5 Soren
+0.8 Norman - I like Bernds idea..
+0.2 Vincenzo
-1 Serge
D4. Use some simple, lightweight form of (auto-)wiring, there must
(added by Bernd, not voted) be something out there (if not XBeans)
+1 Bernd
E. Specific API Components issues:
E1. Use JNDI to lookup datasources
-0 Stefano - I'm still undecided about this: I think that using DI would
be better.
Bernd - tough question. my brief insight into this topic tells me that
it's very wrong how it is today, but exposing the interfaces directly?
_That's_ where I'd like to see JNDI! But I don't think I am aware of
enough discussion concerning this topic to vote it.
Noel - Again, premature and possibly container dependent.
+0.5 Soren
+0 Norman - like i said no expirences with JNDI
+0.2 Vincenzo
-1 Serge
E2. Use JNDI to lookup users/mail repositories, the store and any other
James component.
-0.5 Stefano
Bernd - tough question. my brief insight into this topic tells me that
it's very wrong how it is today, but exposing the interfaces directly?
_That's_ where I'd like to see JNDI! But I don't think I am aware of
enough discussion concerning this topic to vote it.
Noel - Again, premature and possibly container dependent.
+0.5 Soren
+0 Norman
+0.2 Vincenzo
-1 Serge
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 Stefano - The API would grow a lot and we'll limit extensibility.
Bernd - tough question. my brief insight into this topic tells me that
it's very wrong how it is today, but exposing the interfaces directly?
_That's_ where I'd like to see JNDI! But I don't think I am aware of
enough discussion concerning this topic to vote it.
Noel - Probably not. That would require the MailetContext to expand to
understand every possible service, and require every possible service.
But some of them? Perhaps.
-0.9 Soren
-0 Norman
+0.5 Vincenzo - for a proper subset (which one :-) ?)
-0.8 Vincenzo - for everything
-1 Serge
E4. Use Dependency Injection (setter based, constructor based, enabling
interfaces, service locator injection) to automatically satisfy
components dependencies.
+1 Stefano - Imo the right way
+1 Bernd - (but I'm also +1 to _optionally_support_ JNDI)
-? Noel - Where? For the Mailet API? -1. Elsewhere in JAMES? To be
determined.
+0.8 Soren
+0.8 Norman
+0 Vincenzo
+1 Serge - setter or construction based
E5. Keep the ServiceManager as a property stored in the MailetContext.
-0.9 Stefano - Imho this is a bad practice and introduce a "hidden"
dependency.
-0.5 Bernd
-0.8 Soren
-0.5 Norman - Seems to be more a hack..
-0.8 Vincenzo
-1 Serge
If you voted +X to something DI related please also vote this:
G. Dependency Injection
Noel made a long comment to this. read it in its message. (-? to DI for
Datasources)
+0 Vincenzo
G1. Use CDI (constructor base DI)
-0 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
-0 Soren
+0 Norman
+0 Vincenzo
+0.5 Serge
G2. Use Setters
+0.8 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
+0.5 Soren
+0.5 Norman
+0 Vincenzo
+1 Serge
G3. Use Setters with Enabling Interfaces
+1 Stefano
+1 Bernd - G1-G3, I am not enough a religious DI fanatic to exclude any
of those
+0.5 Soren
+0.5 Norman
+0 Vincenzo
-1 Serge
G4. Keep single setter for ServiceLocator (ala Avalon)
-0 Stefano
-0 Bernd - all other options are superior
-0.8 Soren
+0 Norman
+0 Vincenzo
-1 Serge
G5. Use reflection and convention over configurations for the above DI
+1 Stefano (even if we may need to add configurability for advanced setups)
+0,5 Bernd
+0.5 Soren
+0 Norman
+0 Vincenzo
-1 Serge
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 Stefano Not avalon friendly, too much xml configuration, big
dependency.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
-1 Noel
+0.5 Soren (I really like Spring)
-0 Norman
+0 Vincenzo
+1 Serge
H2. Use XBean
-0.5 Stefano - I'd like to see what path is followed by Geronimo and
Directory in this aspect. I would not be an early user.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
Noel - Premature. And where?
+0 Soren
+0 Norman
+0 Vincenzo
+0 Serge
H3. Use OSGi Declarative Services
-0 Stefano - There is much going on under the hood of OSGi services.
iPOJO may become interesting, but this is all new stuff and we have a
small developer community, we should learn from others.
+1 Bernd H1-H3 (sigh, if we only where _that_ far already, I'd take any
of these :-) )
+? Noel - This is my preferred direction. But does that mean that
Mailets should be OSGi components? No.
-0 Soren
+0.5 Norman
+0 Vincenzo
-0 Serge
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
