You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2011/01/11 16:05:11 UTC
[proposal] more modules consolidation
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Norman Maurer <no...@apache.org>.
Comments inside..
2011/1/11 Eric Charles <er...@apache.org>:
> (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.
+1
> - 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).
I think we would even be flexible with stefano's proposal.
> - If we have to merge project, I would even simply move them out of server,
> having a persistence project such as imap, mailbox,...
-1 I think we will just end up with just another project wich we need
to release before a server release can get cut..
> - 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
>>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Norman Maurer <no...@apache.org>.
I think move stuff out of server should not get done.. Also I think we
would make better just call it "jpa", "jcr" ... No need to prefix it
with persistence.
Bye,
Norman
2011/1/11 Eric Charles <er...@apache.org>:
> 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: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Eric Charles <er...@apache.org>.
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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Stefano Bagnara <ap...@bago.org>.
>> Reducing the number of modules from 43 to 35 brings our average to 10
>> classes per module and it's clear we are still far lower than the
>> average "new" java project.
> When you say module what exactly you count ? It sound like you not
> count the "<module></module> in the pom.xml..
Yes, in james-server/trunk/pom.xml we have 43 <modules>.
Other projects I mentioned have multilevel structure so I counted all
of the tree nodes as nesting them does not eliminate their existence
(maybe this confused you on the numbers :-) )
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Norman Maurer <no...@apache.org>.
Hi,
comments inside again :)
2011/1/11 Stefano Bagnara <ap...@bago.org>:
> 2011/1/11 Eric Charles <er...@apache.org>:
>> (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).
>
> Yes, depending on how you read "micro". I'd say micro is 10-20
> classes, not 1-2 classes :-)
> Othewise OSGI should be better changed to load single classes as
> modules because it doesn't make sense to use jar as container of a
> single class :-)
>
> I agree that we should support OSGi but I think that what I'm
> proposing doesn't prevent osgi support: if instead there is some osgi
> blocker I'd like to know (i'm not an osgi guru, for sure).
>
> I like statistics:
> James 2.3 was 318 classes in a single module (and it included
> protocols and mailets)
> James-Trunk is 363 classes and 43 modules (an average of 8 classes per
> module), if you add protocols, mailets, imap, mailbox we reach more
> than 70 "private" jars in james distribution.
>
> So we moved from 318 to 8: a big jump.. maybe too big.
Statistics are fun :)
>
> I see both versions as bad extremes and that the best is in the
> middle: while a single monolitic product was a showstopper for new
> developers I think the same is true also when a developer wants to
> make a change to james and find that james is composed by 70 modules.
> Unless it is clear what we have in each module then we failed again
> with that goal..
>
I agree with you maybe we should "step-back" and merge some of them again..
> Out of curiosity I had a look at other projects I happen to have checked out:
> - felix (they should know osgi well) includes 2485 classes in 126
> modules (20 classes per module). interesting they have big core
> modules like org.osgi.foundation with 423 classes, org.osgi.compendium
> with 160 and org.osgi.core with 50.
> - activemq counts 1616 classes in 18 modules (89 classes average)
To be honest I think activemq packaging suxx. They should at least
provide some "client-only" jar for those who don't want to run an
embedded broker. I remeber there is a ticket for that which lack some
love..
> - cassandra counts 429 classes in 8 modules (54 avg)
>
Same as above
> Reducing the number of modules from 43 to 35 brings our average to 10
> classes per module and it's clear we are still far lower than the
> average "new" java project.
When you say module what exactly you count ? It sound like you not
count the "<module></module> in the pom.xml..
>
>> - 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.
>
> If we don't need jdbc anymore we can't drop it, but this is "another
> issue" for another thread (first we have to provide a mail-jpa
> implementation I guess, unless we drop mail-* too).
true..
>
>> - 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).
>
> Yes, consolidating the modules doesn't prevent mixed configurations.
> When you import an osgi bundle you are not forced to use all of the
> classes...
> As I wrote I think "most" users will use a single persistence and that
> should be the easy way: "fewer" users will use more advanced
> configurations and we should support them too.
> I guess no flexibility is compromised by consolidating modules like a
> proposed, but maybe I missed something....
+1, I agree
>
>> [from another mail]
>> - 'persistence' naming is well representative, but we also have the 'mailbox' which is the mail persistence: I expect confusions for new-comers...
>
> I agree.
> FWIW i find already "confusing" to have mail-jcr in server-james and
> jcr in the mailbox product so I think we're only "moving" entropy
> around and not increasing entropy :-)
>
> On the other side maybe the current "mailbox-adapter" have something
> generic and something specific to the mailbox implementation used: I
> see we have maildir specific code there, not sure why we don't have
> the same specific code for jpa and jcr too. If we move to
> "persistence-$type" modules then we could add a "mailbox" package to
> each one for the specific wrapping stuff: persistence-file/mailbox
> would use mailbox-maildir, persistence-jcr/mailbox would contain
> mailbox-jcr specific adapters and so on.. (maybe I'm just saying
> stupid things.. I don't know mailbox enough.. just had a look at the
> mailbox-adapter module in server-trunk).
Well the maildir stuff is a bit of some special "glue" code.. It's
only needed because we want to use some special parent dir depending
if we use virtualhosting or not.
>
> This has minor drawbacks because importing "persistence-file" would
> bring also mailbox-maildir dependency but for a newbie developer (and
> for me too, not sure this qualify me as newbie too ) this would
> probably make easier to find stuff.
I see your point, but I'm not 100% convided yet ;)
>
> Stefano
>
> ---------------------------------------------------------------------
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Stefano Bagnara <ap...@bago.org>.
2011/1/11 Eric Charles <er...@apache.org>:
> (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).
Yes, depending on how you read "micro". I'd say micro is 10-20
classes, not 1-2 classes :-)
Othewise OSGI should be better changed to load single classes as
modules because it doesn't make sense to use jar as container of a
single class :-)
I agree that we should support OSGi but I think that what I'm
proposing doesn't prevent osgi support: if instead there is some osgi
blocker I'd like to know (i'm not an osgi guru, for sure).
I like statistics:
James 2.3 was 318 classes in a single module (and it included
protocols and mailets)
James-Trunk is 363 classes and 43 modules (an average of 8 classes per
module), if you add protocols, mailets, imap, mailbox we reach more
than 70 "private" jars in james distribution.
So we moved from 318 to 8: a big jump.. maybe too big.
I see both versions as bad extremes and that the best is in the
middle: while a single monolitic product was a showstopper for new
developers I think the same is true also when a developer wants to
make a change to james and find that james is composed by 70 modules.
Unless it is clear what we have in each module then we failed again
with that goal..
Out of curiosity I had a look at other projects I happen to have checked out:
- felix (they should know osgi well) includes 2485 classes in 126
modules (20 classes per module). interesting they have big core
modules like org.osgi.foundation with 423 classes, org.osgi.compendium
with 160 and org.osgi.core with 50.
- activemq counts 1616 classes in 18 modules (89 classes average)
- cassandra counts 429 classes in 8 modules (54 avg)
Reducing the number of modules from 43 to 35 brings our average to 10
classes per module and it's clear we are still far lower than the
average "new" java project.
> - 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.
If we don't need jdbc anymore we can't drop it, but this is "another
issue" for another thread (first we have to provide a mail-jpa
implementation I guess, unless we drop mail-* too).
> - 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).
Yes, consolidating the modules doesn't prevent mixed configurations.
When you import an osgi bundle you are not forced to use all of the
classes...
As I wrote I think "most" users will use a single persistence and that
should be the easy way: "fewer" users will use more advanced
configurations and we should support them too.
I guess no flexibility is compromised by consolidating modules like a
proposed, but maybe I missed something....
> [from another mail]
> - 'persistence' naming is well representative, but we also have the 'mailbox' which is the mail persistence: I expect confusions for new-comers...
I agree.
FWIW i find already "confusing" to have mail-jcr in server-james and
jcr in the mailbox product so I think we're only "moving" entropy
around and not increasing entropy :-)
On the other side maybe the current "mailbox-adapter" have something
generic and something specific to the mailbox implementation used: I
see we have maildir specific code there, not sure why we don't have
the same specific code for jpa and jcr too. If we move to
"persistence-$type" modules then we could add a "mailbox" package to
each one for the specific wrapping stuff: persistence-file/mailbox
would use mailbox-maildir, persistence-jcr/mailbox would contain
mailbox-jcr specific adapters and so on.. (maybe I'm just saying
stupid things.. I don't know mailbox enough.. just had a look at the
mailbox-adapter module in server-trunk).
This has minor drawbacks because importing "persistence-file" would
bring also mailbox-maildir dependency but for a newbie developer (and
for me too, not sure this qualify me as newbie too ) this would
probably make easier to find stuff.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Eric Charles <er...@apache.org>.
(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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [proposal] more modules consolidation
Posted by Norman Maurer <no...@apache.org>.
Hi Stefano,
the idea was to make it easy to use and deploy them in an osgi
container without the need to not needed dependencies.. You know in
OSGI you will see a dependency hell really fast ;)
For details see inline..
2011/1/11 Stefano Bagnara <ap...@bago.org>:
> 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!
Wow I wasn'T aware that we have such many ;)
> 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)
I can see your point and I think at the end it would work even in
OSGI. You would just need to be sure that the "*-api" is in place. So
I think the *-api modules should stay..
>
> - 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)
>
Need to review the impact. Not sure atm
> - 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)
>
I see your point. So +1...
> 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
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org