Commenting while thinking:
- moving persistence-* out-of- server sounded good to me, but we will
face release issue (a release is some work), so it should be forgotten.
- 'persistence' naming is well representative, but we also have the
'mailbox' which is the mail persistence: I expect confusions for
new-comers...
Tks,
Eric
On 11/01/2011 18:05, Eric Charles wrote:
(quick answer)
- Yes, 43 is much... The idea behind was the osgi track (can't find
the articles from pax project where they argue to have real small
modules, even micro modules, rather than larger one).
- Your proposal to have persistence-* is good because it will not
oblige to load unneeded dependencies (if you need jpa, you don't have
jcr,..)
- Btw, must we keep jdbc. I would simply deprecate it in favor of jpa.
- I think some user will still use mixed persistence (ex: ldap for
user and maildir for mailbox), so I would prefer keeping all
flexibility (this is why we have no fk in jpa between user and mailbox).
- If we have to merge project, I would even simply move them out of
server, having a persistence project such as imap, mailbox,...
- No idea about queue-*.
Tks,
Eric
On 11/01/2011 16:05, Stefano Bagnara wrote:
You know I finally had some time to review current trunk and I fear we
have too many modules: we removed protocols, imap and mailets but
still we have 43 modules. 43!
Many modules counting less than 4 classes.
Here is a choice of current modules and the number of classes they
contains:
- mail-file(3)
- mail-jcr(1)
- mail-jdbc(3)
- user-jpa(4)
- user-file(2)
- user-jcr(2)
- user-jdbc(4)
- domainlist-jpa(2)
- domainlist-xml(1)
I only see benefits and no drawbacks in consolidating the 9 modules
above to the following 4 modules:
persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
- mail-library(1)
- domainlist-library(2)
- user-library(9)
We could consolidate them into a persistence-library module (from 3 to
1 module).
persistence-library(12) =
mail-library(1)+domainlist-library(2)+user-library(9)
- queue-library(2)
- queue-jms(5)
We could merge queue-library to queue-jms (a library module makes
sense when we do something useful.. if it is trivial stuff it can be
duplicated or moved to the api layer).
queue-jms(7) = queue-jms(5)+queue-library(2)
The 3 steps above would reduce the number of modules of 8.
The main advantages of using modules is being able to isolate
dependencies, so I consolidated modules sharing the same dependencies.
To understand what "module" is implemented by each persistence adaptor
one can easily look at the packages inside the module.
If people will one day contribute mail-jpa code or domainlist-jcr or
domainlist-jdbc we don't have to add 3 new modules but simply really
few new classes to their respective persistence functions. If we had
the 3 missing implementations we could bring this "consolidation" also
to the configuration side: while I see cases where mixed persistence
is used, in my opinion most users will simply stick to a single
persistence type for everthing. So it would be convenient to simply
let the user choose the persistence method (file, jdbc, jcr, jpa) and
then automatically choose the 3 right service implementations.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
