On Sat, Nov 28, 2009 at 6:22 PM, Felix Meschberger <fmesc...@gmail.com> wrote:
> That's what we currently do in the Sling embedded repository bundle [1]
Hi Felix,
Thanks for the reply during weekend:)
I saw all dependencies jars are embedded to jackrabbit-server bunlde.
Bundle-ClassPath: .,jackrabbit-jcr-rmi-1.4.1.jar,jackrabbit-core-1.6.0
.jar,jackrabbit-jcr-commons-1.6.0.jar,jackrabbit-spi-commons-1.6.0.ja
r,jackrabbit-spi-1.6.0.jar,lucene-core-2.4.1.jar,derby-10.2.1.6.jar,c
oncurrent-1.3.4.jar,jackrabbit-text-extractors-1.6.0.jar,pdfbox-0.7.3
.jar,jempbox-0.2.0.jar,fontbox-0.1.0.jar,poi-3.2-FINAL.jar,poi-scratc
hpad-3.2-FINAL.jar,nekohtml-1.9.7.jar,xercesImpl-2.8.1.jar
This is a good workaround for libs which isn't OSGified, I did the
similar way by generate jar file contain all none OSGfied classes.
<instructions>
<DynamicImport-Package>*</DynamicImport-Package>
<Export-Package>foo.bar.jcr*</Export-Package>
<Private-Package>
org.apache.jackrabbit*,
org.apache.derby*,
org.apache.tika*,
org.apache.lucene*,
org.apache.commons.io*,
org.apache.commons.pool*,
org.apache.commons.collections*,
org.apache.xerces*,
org.pdfbox*,
org.textmining*,
EDU*,
META-INF.services*
</Private-Package>
<Import-Package>
javax.jcr*;version="[2.0,3.0)",
org.apache.derby.jdbc;resolution:=optional,
com.mysql.jdbc;resolution:=optional,
*;resolution:=optional
</Import-Package>
</instructions>
But I have to say that it's not a beautiful way to work in OSGi
environment. We should use proper OSGi header for all jackrabbit jars
for long run. Eventually, all dependencies could be provided by OSGi.
In short term, there could be a bundle to provide all none OSGified
packages, in sling case, it could be at jackrabbit-server bundle.
The repository management is key part of jcr based solutions, so I
expect most of users will do something configuration/coding to meet
their special operation requirement. So embedded private jackrabbit
packages leave little space to do that.
What problem can you see to just add OSGi headers in jackrabbit
project? By this way, I didn't see any reason for users to repackage
jackrabbit for OSGi deployment.
-Guo
