jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] One Project
Date Tue, 30 Nov 2010 10:42:36 GMT
Hi,

* code coverage over multiple modules. I'm pretty sure Sonar does this.

Good to know. What would be required for that? Could you provide a patch?

* Having one jar for users doesn't necessarily have to imply losing build
modularity.

What does 'build modularity' mean exactly? What are the advantages to
create many projects? The disadvantages (in my view) is unnecessary added
complexity. I guess you know the quote "Make everything as simple as
possible, but not simpler." In my view, simple as possible means only
creating the projects that are really necessary. For each added project
there needs to be a very good reason, because every added project comes
with a cost (administrative overhead, added burden when developing, added
documentation, added complexity).

* I've never found the build modularity to be a problem as a developer
(I've made a few Jackrabbit patches).

That's good to know. My experience (as a Jackrabbit committer) is
different. You may not have worked on things like the SQL-2 parser (where
the test cases are in a different project than the source code!). Yes,
probably it would be possible to merge them back together (as it
originally was). However, there would be quite some effort to do that,
effort I'm not willing to spend, because it is pure overhead! For me, the
number of projects within Jackrabbit feels like I'm lost in some kind of
jungle. For me, developing Jackrabbit sometimes doesn't feel like
developing, it feels more like trying to satisfy some kind of bureaucratic
system. When such a bureaucracy has advantages, then that's fine, but I
fail to see the advantages for Jackrabbit 3 (I see it does have advantages
for Jackrabbit 2 - we don't need to talk about that). That's why I want to
simplify things for Jackrabbit 3, at least at the beginning, when there
will be many code changes. So that developing once again feels like
developing.

*  Since I know Maven I've been able to dive into the build with no issues
because it's pretty standard.

I don't mean to use anything non-standard. I think reducing the number of
projects for Jackrabbit 3 will result in a simpler, more standard build.

* I think there is a lot of value in keeping the build modular because it
keeps the code clean and interdependencies at a minimum. Jackrabbit code
is very clean and well laid out, making it easy to hack.

Do you equate a huge number of project with "clean"?? I equate it with
dirty. What do you mean with "keep the build modular"? Using multiple
projects doesn't magically reduce the dependencies. In my view, the
Jackrabbit code is quite unclean actually, for example there are few
tests, and things are unnecessarily complex. But that's just my view.

* We as a company don't use all the Jackrabbit modules, so it's nice to
only have to use the modules we need. Things like WebDAV or OCM aren't
necessary for what we're doing.

Are you concerned about the jar file size? What is the maximum jar file
size for you? Why do you have the jar file size constraint, does your
system not have hard disk space (memory doesn't count, because the JVM
doesn't load unused classes)? Do you run Jackrabbit on Android? I have
never heard any request to reduce the jar file size of Jackrabbit, so the
reason Jackrabbit is split into multiple projects is definitely not to
reduce jar file size. As far as I know, OCM is not part of Jackrabbit
trunk. As for WebDAV, I would probably keep it separate (not implement it
in Jackrabbit 3 at the beginning), I guess that's something we need to
decide soon.

> if you really want to have a single jar to start jackrabbit,
> you have to include 3rd party jars used by jr

If we include all dependencies (such as Apache Commons jar files) you
would need a special class loader, right? Otherwise there may be conflicts
with if somebody already uses a different version of a Apache Commons
library that Jackrabbit also uses. That would be quite complex I guess, so
I wouldn't do that. Instead, I would just concentrate on having as few jar
files as possible. I think it would be an advantage if we could reduce the
number of dependencies however (maybe even make Lucene optional - that
would allow to use Jackrabbit on Android).

Regards,
Thomas


Mime
View raw message