2014-03-12 12:29 GMT+01:00 Tommaso Teofili <tommaso.teof...@gmail.com>:
>
>
>
> 2014-03-12 12:01 GMT+01:00 Chetan Mehrotra <chetan.mehro...@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.teof...@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.teof...@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.teof...@gmail.com
>> >:
>> >>
>> >> ah ok, thanks for clarifying.
>> >>> Regards,
>> >>> Tommaso
>> >>>
>> >>>
>> >>> 2014-03-10 18:10 GMT+01:00 Jukka Zitting <jukka.zitt...@gmail.com>:
>> >>>
>> >>> Hi,
>> >>>>
>> >>>> On Mon, Mar 10, 2014 at 1:01 PM, Tommaso Teofili
>> >>>> <tommaso.teof...@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
>> >>>>
>> >>>
>> >>>
>> >>
>>
>
>
