You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/11/27 14:50:14 UTC
Sling's use of Jackrabbit
FYI
I have started a thread in the Apache Sling project regarding the future
of the Jackrabbit-based OSGi bundles we maintain [1].
One option (out of my belly) could be to create an OSGi subproject in
Jackrabbit which would host these bundles.
You are invited to follow this discussion and of coure also share your
opinions.
Should the result of the Sling discussion be to "donate" some or all of
the bundles to the Jackrabbit project, I will come back to officially
offer these bundles to the Jackrabbit community.
Regards
Felix
[1] http://markmail.org/thread/vechl274bewkh4o6
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Mon, Nov 30, 2009 at 10:44 AM, Thomas Müller <th...@day.com> wrote:
> I would wait until it's a real problem. Trying to solve _potential_
> problems in advance is usually the wrong path.
I understand it will take effort/risk to do it.
Thanks for the discussion and all your hard works!
-Guo
Re: Sling's use of Jackrabbit
Posted by Thomas Müller <th...@day.com>.
Hi,
> I don't have another implementation at the moment for any of them.
OK, good to know.
> I can think of it's might be possible to add key/value store as bundle
> persistence store in future.
I would wait until it's a real problem. Trying to solve _potential_
problems in advance is usually the wrong path.
Regards,
Thomas
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Mon, Nov 30, 2009 at 9:59 AM, Thomas Müller <th...@day.com> wrote:
> I would do that only if there is an actual need for it. Do you have
> another implementation? Persistence manager, data store, or journal?
> If yes, would it be enough to just move the persistence manager
> interface, or do we need to do something else (for example does your
> implementation extend the abstract bundle persistence manager)?
I don't have another implementation at the moment for any of them. But
I can think of it's might be possible to add key/value store as bundle
persistence store in future. From the exist implementation names such
as DerbyPersistenceManager, Oracle9PersistenceManager,
CachingPersistenceManager, you can see that there would endless of
possibility for new implementations :(
I don't see too much benefit now to move the interface to API, but it
would have a clean way to extend jackrabbit for long run.
-Guo
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
> On Mon, Nov 30, 2009 at 14:23, Thomas Müller <th...@day.com> wrote:
>> As I already wrote, it doesn't make sense to do that now. We can still
>> do that later on, when there is actually somebody that needs it.
>
> AFAIU the workaround done in Sling wrt the package exports is a bit
> ugly, hence there is some need for it to make it cleaner. Also, the
> 2.0 release is the best candidate for introducing such changes. We
> can't change that API part in 2.x.
As I also said, the API part is only one part. The other part is
dynamicity which we also have to account for (since Jackrabbit Core
doesn't and will probably not in the foreseeable future).
But I am basically all for isolating part of the internal API into
Jackrabbit Core API packages. Maybe PersistenceManager is not the best
idea, but the Authentication and Access Control stuff are certainly
candidates.
Regards
Felix
>
> Regards,
> Alex
>
Re: Sling's use of Jackrabbit
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Dec 1, 2009 at 13:37, Thomas Müller <th...@day.com> wrote:
> I understand we should not _change_ (or remove) a public API within
> 2.x. That's actually the main reason why I wouldn't export the
> PersistenceManager API now, because it would force us to keep it like
> it is for the whole 2.x.
>
> But we can still export _additional_ packages within 2.x (for example,
> export the PersistenceManager API in 2.1 or 2.2 if really needed).
I see, makes sense.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Sling's use of Jackrabbit
Posted by Thomas Müller <th...@day.com>.
Hi,
> We can't change that API part in 2.x.
I understand we should not _change_ (or remove) a public API within
2.x. That's actually the main reason why I wouldn't export the
PersistenceManager API now, because it would force us to keep it like
it is for the whole 2.x.
But we can still export _additional_ packages within 2.x (for example,
export the PersistenceManager API in 2.1 or 2.2 if really needed).
Regards,
Thomas
Re: Sling's use of Jackrabbit
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Nov 30, 2009 at 14:23, Thomas Müller <th...@day.com> wrote:
> As I already wrote, it doesn't make sense to do that now. We can still
> do that later on, when there is actually somebody that needs it.
AFAIU the workaround done in Sling wrt the package exports is a bit
ugly, hence there is some need for it to make it cleaner. Also, the
2.0 release is the best candidate for introducing such changes. We
can't change that API part in 2.x.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Sling's use of Jackrabbit
Posted by Thomas Müller <th...@day.com>.
Hi,
>> I would not move the API to the Jackrabbit API. Just moving the
>> interfaces into sepatate packages, eg. below o.a.j.core.api would
>> suffice it to export this space and leave the implementation private.
>
> +1
>
> Moving the persistence manager interface and co (basically everything
> that can be swapped by custom implementations in the repository.xml)
> into a separate API package is a good idea. But it makes sense to
> separate this from the client-side API in jackabbit-api and only have
> this as an exported package in jackrabbit-core.
-1
As I already wrote, it doesn't make sense to do that now. We can still
do that later on, when there is actually somebody that needs it.
Regards,
Thomas
Re: Sling's use of Jackrabbit
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Nov 30, 2009 at 11:09, Felix Meschberger <fm...@gmail.com> wrote:
>>> It's worth to move some of the internal API to jackrabbit-api
>>> for other bundle to provide different implementation. Tt could well
>>> documented and better for third party to extend the jackrabbit.
>>
>> I would do that only if there is an actual need for it. Do you have
>> another implementation? Persistence manager, data store, or journal?
>> If yes, would it be enough to just move the persistence manager
>> interface, or do we need to do something else (for example does your
>> implementation extend the abstract bundle persistence manager)?
>
> I would not move the API to the Jackrabbit API. Just moving the
> interfaces into sepatate packages, eg. below o.a.j.core.api would
> suffice it to export this space and leave the implementation private.
+1
Moving the persistence manager interface and co (basically everything
that can be swapped by custom implementations in the repository.xml)
into a separate API package is a good idea. But it makes sense to
separate this from the client-side API in jackabbit-api and only have
this as an exported package in jackrabbit-core.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Thomas Müller schrieb:
> Hi,
>
>> It's worth to move some of the internal API to jackrabbit-api
>> for other bundle to provide different implementation. Tt could well
>> documented and better for third party to extend the jackrabbit.
>
> I would do that only if there is an actual need for it. Do you have
> another implementation? Persistence manager, data store, or journal?
> If yes, would it be enough to just move the persistence manager
> interface, or do we need to do something else (for example does your
> implementation extend the abstract bundle persistence manager)?
I would not move the API to the Jackrabbit API. Just moving the
interfaces into sepatate packages, eg. below o.a.j.core.api would
suffice it to export this space and leave the implementation private.
And yes, there is potentially a requirement/use for it: In Day we
implement so-called Connectors to other (legacy) systems like
Documentum, Sharepoint etc. Being able to "attach" these to the
repository with proper bundling would help much in terms of development
and deployment efforts.
Regards
Felix
Re: Sling's use of Jackrabbit
Posted by Thomas Müller <th...@day.com>.
Hi,
> It's worth to move some of the internal API to jackrabbit-api
> for other bundle to provide different implementation. Tt could well
> documented and better for third party to extend the jackrabbit.
I would do that only if there is an actual need for it. Do you have
another implementation? Persistence manager, data store, or journal?
If yes, would it be enough to just move the persistence manager
interface, or do we need to do something else (for example does your
implementation extend the abstract bundle persistence manager)?
Regards,
Thomas
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Guo Du schrieb:
> On Mon, Nov 30, 2009 at 9:02 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> The problem of Jackrabbit Core is, that apart from implementing the
>> Jackrabbit API (which is imported in the bundle), it has its internal
>> API (for example the PersistenceManager interface or others). This
>> internal API is not properly separated (in terms of Java Packages) from
>> implementation classes, which should not leak into the exported package
>> space.
> jackrabbit is a few years old and at that time OSGi may not in the big
> picture. It's worth to move some of the internal API to jackrabbit-api
> for other bundle to provide different implementation. Tt could well
> documented and better for third party to extend the jackrabbit.
>
>
>> One of the major issues still remaining is providing persistence
>> managers as OSGi bundles. The only feasible, yet not very clean
>> approach, would be to use fragment bundles.
> I prefer stay way from fragment if possible :)
I agree absolutely.
Regards
Felix
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Mon, Nov 30, 2009 at 9:02 AM, Felix Meschberger <fm...@gmail.com> wrote:
> The problem of Jackrabbit Core is, that apart from implementing the
> Jackrabbit API (which is imported in the bundle), it has its internal
> API (for example the PersistenceManager interface or others). This
> internal API is not properly separated (in terms of Java Packages) from
> implementation classes, which should not leak into the exported package
> space.
jackrabbit is a few years old and at that time OSGi may not in the big
picture. It's worth to move some of the internal API to jackrabbit-api
for other bundle to provide different implementation. Tt could well
documented and better for third party to extend the jackrabbit.
> One of the major issues still remaining is providing persistence
> managers as OSGi bundles. The only feasible, yet not very clean
> approach, would be to use fragment bundles.
I prefer stay way from fragment if possible :)
-Guo
Re: Sling's use of Jackrabbit
Posted by Thomas Müller <th...@day.com>.
Hi,
> The problem of Jackrabbit Core is, that apart from implementing the
> Jackrabbit API (which is imported in the bundle), it has its internal
> API (for example the PersistenceManager interface or others). This
> internal API is not properly separated (in terms of Java Packages) from
> implementation classes, which should not leak into the exported package
> space.
If this really is an issue, we should try to solve it. Is is really an
issue? A solution might be to move the PersistenceManager and other
interfaces to jackrabbit-api (would we need to change the package
name?).
Regards,
Thomas
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Marcel Reutegger schrieb:
> On Mon, Nov 30, 2009 at 10:02, Felix Meschberger <fm...@gmail.com> wrote:
>> This leaves just xerces and lucene (and a few smaller libraries) inside
>> the jackrabbit-bundle. Lucene is ok, because Jackrabbit IIRC is closes
>> knitted with Lucene.
>
> actually not at all. it is perfectly hidden behind the QueryHandler
> interface. the implementation just currently resides in
> jackrabbit-core, but could easily be moved into a separate module.
So, theoretically, lucene could be omitted from the bundle and just be
imported -- provided Lucene provides a bundle which does not seem to be
the case yet.
Regards
Felix
>
> regards
> marcel
>
Re: Sling's use of Jackrabbit
Posted by Marcel Reutegger <ma...@gmx.net>.
On Mon, Nov 30, 2009 at 10:02, Felix Meschberger <fm...@gmail.com> wrote:
> This leaves just xerces and lucene (and a few smaller libraries) inside
> the jackrabbit-bundle. Lucene is ok, because Jackrabbit IIRC is closes
> knitted with Lucene.
actually not at all. it is perfectly hidden behind the QueryHandler
interface. the implementation just currently resides in
jackrabbit-core, but could easily be moved into a separate module.
regards
marcel
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
HI,
Guo Du schrieb:
> On Sat, Nov 28, 2009 at 6:22 PM, Felix Meschberger <fm...@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.
Yes, this was for simplicity and "speed". I am currently trying to
migrate the jackrabbit-server bundle to Jackrabbit 2 (beta3) and went a
different route:
* I moved the derby library out thus leveraging Derby as a bundle
* As of Jackrabbit 2 Tika is used for text extraction (and other
tasks). Tika already comes partially bundleized and I am working
on a patch to create a "Tika Full" bundle.
This leaves just xerces and lucene (and a few smaller libraries) inside
the jackrabbit-bundle. Lucene is ok, because Jackrabbit IIRC is closes
knitted with Lucene. And Xerces, well, this is a nasty beast which can
probably not easily be turned into a bundle, not to speak of versioning
isseus....
I will post some information on my progress to the Sling wiki shortly.
>
> 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.
Agreed. See above.
>
> 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.
We have done that for a few projects already: Jackrabbit API, Jackrabbit
JCR Commons, Jackrabbit JCR RMI. For others it is not that easy, and
Jackrabbit Core is one of those.
The problem of Jackrabbit Core is, that apart from implementing the
Jackrabbit API (which is imported in the bundle), it has its internal
API (for example the PersistenceManager interface or others). This
internal API is not properly separated (in terms of Java Packages) from
implementation classes, which should not leak into the exported package
space.
So what we have done in Sling is define additional API, which may be
used as service interfaces and which is bridged into the Repository.
This also allows for some configuration flexibility.
One of the major issues still remaining is providing persistence
managers as OSGi bundles. The only feasible, yet not very clean
approach, would be to use fragment bundles.
Anyway, this is also fragile, because the Jackrabbit core implementation
is not currently built to support dynamic arrival and departure of
persistence managers ... A solution here would probably also be to
provide some bridging.
Regards
Felix
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Sat, Nov 28, 2009 at 6:22 PM, Felix Meschberger <fm...@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
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Guo Du schrieb:
> On Fri, Nov 27, 2009 at 8:20 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Issue is that Jackrabbit is configured with a repository.xml file which
>> itself refers to optional classes. Most notably these are the
>> PersistenceManager classes along with their dependencies. So this
>> provides some issues with setting up the bundle.
> OSGi DynamicImport-Package header is designed to work with this
> situation. It was used to work with dynamic environment such as groovy
> or templating.
This might be an option, yes.
>
>> In addition there might be requirements to flexibly add LoginModule(s)
>> in OSGi style using the OSGi service registry. This is not available
>> from the jackrabbit-core library and we have added support for this in
>> Sling.
> As repository.xml was the core to boot up the repository, the lookup
> LoginModule from OSGi service could be an helper class aware of
> bundleContext to get reference from other bundle. It may not worth to
> add OSGi dependencies to JR core.
That's what we currently do in the Sling embedded repository bundle [1]
Regards
Felix
[1]http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/jackrabbit-server
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Fri, Nov 27, 2009 at 8:20 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Issue is that Jackrabbit is configured with a repository.xml file which
> itself refers to optional classes. Most notably these are the
> PersistenceManager classes along with their dependencies. So this
> provides some issues with setting up the bundle.
OSGi DynamicImport-Package header is designed to work with this
situation. It was used to work with dynamic environment such as groovy
or templating.
> In addition there might be requirements to flexibly add LoginModule(s)
> in OSGi style using the OSGi service registry. This is not available
> from the jackrabbit-core library and we have added support for this in
> Sling.
As repository.xml was the core to boot up the repository, the lookup
LoginModule from OSGi service could be an helper class aware of
bundleContext to get reference from other bundle. It may not worth to
add OSGi dependencies to JR core.
-Guo
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Guo Du schrieb:
> On Fri, Nov 27, 2009 at 7:48 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> That's exactly why I intent to go this route.
> Great to see it happens, hope before 2.0 final release:)
If possible, but there is no guarantee.
>
>> But it is important to understand that there are some use cases for
>> dynamic configurability of the embedded Jackrabbit instance which we
>> will have to ensure in the future.
> Can you explain "dynamic configurability" and "embedded Jackrabbit" in
> the context of JR deployment topology:
> JR standalone jar
> JR embedded to web application
Not sure, whether this is related ...
> JR embedded to an OSGi bundle
Issue is that Jackrabbit is configured with a repository.xml file which
itself refers to optional classes. Most notably these are the
PersistenceManager classes along with their dependencies. So this
provides some issues with setting up the bundle.
In addition there might be requirements to flexibly add LoginModule(s)
in OSGi style using the OSGi service registry. This is not available
from the jackrabbit-core library and we have added support for this in
Sling.
> JR as OSGi bundle to provide RepositoryFactory service
Not sure, whether this is of importance in an OSGi framework: The
embedded repository is exposed as an OSGi service in the OSGi service
registry. Use is as simple as getting the repository from the service
registry.
The embedded repository bundle is itself ensuring the repository is started.
It is conceivable to also provide RepositoryFactory service, but there
has not been such a requirement yet (maybe also because this is new in
JCR 2).
> JR remotely with webdav or API
Providing remote access to the repository embedded in an OSGi framework
is actually very easy: The WebDAV component is installed as an OSGi
bundle and by means of the OSGi HttpService exposes the repository. We
have done this with the Jackrabbit WebDAV bundle in Sling.
Regards
Felix
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
On Fri, Nov 27, 2009 at 7:48 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> That's exactly why I intent to go this route.
Great to see it happens, hope before 2.0 final release:)
>
> But it is important to understand that there are some use cases for
> dynamic configurability of the embedded Jackrabbit instance which we
> will have to ensure in the future.
Can you explain "dynamic configurability" and "embedded Jackrabbit" in
the context of JR deployment topology:
JR standalone jar
JR embedded to web application
JR embedded to an OSGi bundle
JR as OSGi bundle to provide RepositoryFactory service
JR remotely with webdav or API
Thanks very much in advance.
-Guo
Re: Sling's use of Jackrabbit
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
That's exactly why I intent to go this route.
But it is important to understand that there are some use cases for
dynamic configurability of the embedded Jackrabbit instance which we
will have to ensure in the future.
Regards
Felix
Guo Du schrieb:
> Hi Felix,
>
> It's really necessary to get jackrabbit OSGified. As OSGi get very
> popular those days. If we don't do it from JR, all other people like
> sling will do it there.
>
> We just add correct OSGi headers all JR projects and that's it. By
> this way, JR won't affect on it's standalone application as well.
>
> For all external dependencies, it's up to the end user to get it when
> deploy to OSGi runtime. Sling is a better place than JR to host
> OSGified dependencies.
>
> -Guo
>
>
> On Fri, Nov 27, 2009 at 1:50 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> I have started a thread in the Apache Sling project regarding the future
>> of the Jackrabbit-based OSGi bundles we maintain [1].
>>
>> One option (out of my belly) could be to create an OSGi subproject in
>> Jackrabbit which would host these bundles.
>>
>> You are invited to follow this discussion and of coure also share your
>> opinions.
>>
>> Should the result of the Sling discussion be to "donate" some or all of
>> the bundles to the Jackrabbit project, I will come back to officially
>> offer these bundles to the Jackrabbit community.
>>
>> Regards
>> Felix
>>
>> [1] http://markmail.org/thread/vechl274bewkh4o6
>
Re: Sling's use of Jackrabbit
Posted by Guo Du <mr...@gmail.com>.
Hi Felix,
It's really necessary to get jackrabbit OSGified. As OSGi get very
popular those days. If we don't do it from JR, all other people like
sling will do it there.
We just add correct OSGi headers all JR projects and that's it. By
this way, JR won't affect on it's standalone application as well.
For all external dependencies, it's up to the end user to get it when
deploy to OSGi runtime. Sling is a better place than JR to host
OSGified dependencies.
-Guo
On Fri, Nov 27, 2009 at 1:50 PM, Felix Meschberger <fm...@gmail.com> wrote:
> I have started a thread in the Apache Sling project regarding the future
> of the Jackrabbit-based OSGi bundles we maintain [1].
>
> One option (out of my belly) could be to create an OSGi subproject in
> Jackrabbit which would host these bundles.
>
> You are invited to follow this discussion and of coure also share your
> opinions.
>
> Should the result of the Sling discussion be to "donate" some or all of
> the bundles to the Jackrabbit project, I will come back to officially
> offer these bundles to the Jackrabbit community.
>
> Regards
> Felix
>
> [1] http://markmail.org/thread/vechl274bewkh4o6