jackrabbit-dev mailing list archives

Hi,
Let me add another word here: We must not drive the architecture of
anything by the desire to avoid public method in internal classes.
This will certainly lead to a bad and unmaintainable design because it
requires mixing classes in the same packages, which do not belong
together from an architectural point of view.
In this respect, the design goal of preventing public methods in fact
prevents modularization completely !
Regards
Felix
On 28.05.2010 12:08, Thomas Müller wrote:
> Hi,
>
> I'm sorry about the tone of my mails.
>
> I just want to avoid that we run into the trap of making Jackrabbit 3
> much too complicated and complex for the sake of being "modular". I
> agree there shouldn't be many public implementation methods, but what
> I don't want to do is add additional "glue" classes to avoid them.
> Adding complexity to conceal bad design, and then call that "good
> design". I would rather have some public methods, if the overall
> design is simpler, than that added indirection.
>
> This is not just about public methods. It's also about splitting
> Jackrabbit 3 into multiple projects. In my view, we should keep it one
> project, and one jar file, at least for now. I believe there are far
> too many projects and jar files in Jackrabbit 2.
>
> Regards,
> Thomas
>