On 14/12/2015 10:56, Benoit Tellier wrote:
In my JAMES-1618 PR I introduced an imMemory UsersRepository (as I
wanted to test SieveRepository integration).
Le 14/12/2015 08:45, Matthieu Baechler a écrit :
On 13/12/2015 12:43, Tellier Benoit wrote:
- Why not introducing /server/data/data-memory for your
MemoryAccessTokenRepository ? I have upcoming commits to create the
project, maybe moving it to data-memory would make sens.
The only rational for not doing it yet is to avoid project
proliferation. We only have a single class in data-jmap for in-memory
implementation.
If you create a server/data/data-memory project, we can put
MemoryAccessTokenRepository in it, that's cool.
I want to ask a really stupid question : "Is project proliferation a bad
thing?"
It is.
Ask yourself if you want to create a Class for every method you need.
It's probably a good think to segregate responsibilities and reuse
everything, but it's not very convenient as it trades developer
efficiency (you need to manage a lot of classes) for modularity.
I see maven modules the same way : we need them to split things, have a
clear architecture, etc, but in the end, too much modules add to the
confusion. It's just a matter of balance.
- What we pay is time to run tests and compile. Small projects that
take ~ 2 s to compile do not seem that expensive.
I will slow up dependency resolution, graph construction, run (because
of classpath size), etc. There's a real cost at this.
- If projects are well organized in a hierarchical structure, we are
not lost, as we can redirect our selves to the right project.
Well organized is not compatible with "too much".
- We should pay attention to code duplication (more on that in my next
mail )
It's when creating modules start to make sense : when there's common
need in different existing modules
- What is dangerous is project for backends nobody is able / volontary
to maintain...
It's armful too, but that another subjet IMO.
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
