jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: [DISCUSS] - OSGi deployment for Oak Lucene / Solr indexers
Date Wed, 12 Mar 2014 16:15:54 GMT
In
https://github.com/tteofili/jackrabbit-oak/blob/oak-1475c/oak-solr-osgi/pom.xmlI've
specialized the above approach only for Solr.

Tommaso


2014-03-12 16:40 GMT+01:00 Tommaso Teofili <tommaso.teofili@gmail.com>:

>
>
> 2014-03-12 12:29 GMT+01:00 Tommaso Teofili <tommaso.teofili@gmail.com>:
>
>
>>
>>
>> 2014-03-12 12:01 GMT+01:00 Chetan Mehrotra <chetan.mehrotra@gmail.com>:
>>
>> Couple of things to try
>>>
>>> * Specify the packages versions via package-info
>>>
>>
>> they're already there in oak-lucene / solr , what should I do more?
>>
>
> I've fixed it with the following Export-Package directive:
>
>                         <Export-Package>
>
> !org.apache.jackrabbit.oak.plugins.index.solr.osgi,
>                             org.apache.jackrabbit.oak.plugins.index.*
>                         </Export-Package>
>
> as the package-info get automatically picked up.
>
>
>>
>>
>>> * Inline the classes instead of embedding the jars
>>>
>>
>> hints on how to do that?
>>
>
>>
>>>
>>> This would enable maven-bundle-plugin to see required
>>> package-info.java file for versions and also the SCR generated files.
>>>
>>> Also can you share your project say on github. Would be easier for me
>>> to try some options
>>>
>>
>> sure:
>> https://github.com/tteofili/jackrabbit-oak/blob/oak-1475b/oak-fulltext/pom.xml
>>
>> Thanks,
>> Tommaso
>>
>>
>>> Chetan Mehrotra
>>>
>>>
>>> On Wed, Mar 12, 2014 at 3:55 PM, Tommaso Teofili
>>> <tommaso.teofili@gmail.com> wrote:
>>> > update on this:
>>> > I've tried the oak-fulltext approach and I found two issues:
>>> > 1. exported packages with semantic versioning from oak-lucene and
>>> oak-solr
>>> > get lost when packing everything together unless they're explicitly
>>> > specified (by hand) in the oak-fulltext maven-bundle-plugin
>>> configuration,
>>> > it can be done but can be tedious (and it's error prone)
>>> > 2. OSGi services exported by oak-lucene and oak-solr don't get
>>> exported by
>>> > oak-fulltext as maven-scr-plugin can look into src/main/java or
>>> classes but
>>> > don't know if / how it could work with embedded jars.
>>> >
>>> > Any suggestions?
>>> > Regards,
>>> > Tommaso
>>> >
>>> >
>>> >
>>> > 2014-03-11 9:00 GMT+01:00 Tommaso Teofili <tommaso.teofili@gmail.com>:
>>> >
>>> >> if there're no other objections / comments I'll go with the last
>>> suggested
>>> >> approach of having oak-lucene and oak-solr not embedding anything and
>>> >> having the oak-fulltext bundle embedding everything needed to make
>>> Lucene
>>> >> and Solr indexers working in OSGi (lucene-*, oak-lucene, solr-*,
>>> >> oak-solr-*, etc.) until we (eventually) get to proper semantic
>>> versioning
>>> >> in Lucene / Solr.
>>> >>
>>> >> As a side effect I don't think it would make sense to keep
>>> >> oak-solr-embedded and oak-solr-remote as separate artifacts so I'd
>>> merge
>>> >> them with oak-solr-core in one oak-solr bundle.
>>> >>
>>> >> Regards,
>>> >> Tommaso
>>> >>
>>> >>
>>> >> 2014-03-10 18:18 GMT+01:00 Tommaso Teofili <tommaso.teofili@gmail.com
>>> >:
>>> >>
>>> >> ah ok, thanks for clarifying.
>>> >>> Regards,
>>> >>> Tommaso
>>> >>>
>>> >>>
>>> >>> 2014-03-10 18:10 GMT+01:00 Jukka Zitting <jukka.zitting@gmail.com>:
>>> >>>
>>> >>> Hi,
>>> >>>>
>>> >>>> On Mon, Mar 10, 2014 at 1:01 PM, Tommaso Teofili
>>> >>>> <tommaso.teofili@gmail.com> wrote:
>>> >>>> > ok, so (in OSGi env) we would have oak-solr and oak-fulltext
as
>>> >>>> fragments
>>> >>>> > of oak-lucene (being the fragment host)
>>> >>>>
>>> >>>> No, that's not what I meant. The proposed oak-fulltext bundle
would
>>> >>>> contain all of oak-lucene, oak-solr, and the Lucene/Solr
>>> dependencies.
>>> >>>> No need for fragment bundles in this case.
>>> >>>>
>>> >>>> BR,
>>> >>>>
>>> >>>> Jukka Zitting
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message