jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Merging components
Date Thu, 22 Oct 2009 09:05:56 GMT


Thomas Müller schrieb:
> Hi,
> 
>> Or better yet, the whole world should be one jar file ;-)
> 
> Or each class could be its own component. We already started with
> jackrabbit-jcr-client.
> 
> Seriously, I think many jackrabbit jar files could be combined. I
> don't see a point in having 10+ jar files for something that is almost
> always used as one component. Splitting a component in multiple jar
> files costs and is risky (development, testing, deployment) and should
> only be done if there is a good reason. Life would be easier for
> everybody if we would combine some projects.

There have been reasons why the components were split in the first place
... So don't go overboard and say "always use it like this" and anything
else I don't care about ....

One use case is using the repository embedded. Another use case is
reusing some of the commons classes. Another use case is an SPI setup,
which does not care about Jackrabbit Core. Etc. Etc.

> 
> Other 'storage backend' products are bundled like this:
> 
> 1 jar file: Lucene (core)
> 1 jar file: HSQLDB
> 1 jar file: Derby (embedded)
> 1 jar file: H2 (embedded & server & client & tools & api)
> 1 file: SQLite (also available as one combined single source file)
> 
> For a Jackrabbit "Hello World" application, I need at least:
> 
> - jackrabbit-core-1.6.0.jar
> - jackrabbit-text-extractors-1.6.0.jar (36 KB)
> - jackrabbit-spi-commons-1.6.0.jar
> - jackrabbit-spi-1.6.0.jar (24 KB)
> - jackrabbit-jcr-commons-1.6.0.jar (212 KB)
> - jackrabbit-api-1.6.0.jar (40 KB)
> - jcr-1.0.jar
> - lucene-core-2.4.1.jar
> - slf4j-log4j12-1.5.3.jar
> - slf4j-api-1.5.3.jar
> - log4j-1.2.14.jar
> - concurrent-1.3.4.jar
> - commons-io-1.4.jar
> - commons-collections-3.1.jar

Of this list, we might create a "embedded" repository JAR file
containing many of these dependencies and require a few to be existing.

For example for an OSGi bundling, you might include the jackrabbit core,
 extractors, spi and commons stuff, lucene, concurrent, commos
io/collections. But you won't include any of the API classes and not
even the SLF4j.

Again, the problem is less the number of jar files (there is a reason to
have them), the problem is missing documentation on what is needed for
what !

Regards
Felix

> 
> Regards,
> Thomas
> 


Mime
View raw message