[
https://issues.apache.org/jira/browse/STANBOL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615426#comment-13615426
]
Rupert Westenthaler commented on STANBOL-1000:
----------------------------------------------
I fully agree with you, but I do not really like the optional dependencies, as
they typically mean that users that try to use that stuff will end up with
ClassNotFoundErrors that are very hard to debug. IMO the better way is to
create own modules for optional solr/lucene modules. Because this will mean
that Solr fails to parse schema.xml files that do use ICU analyzers - an error
that is much easier to deal with.
So in the case of ICU I would suggest to create a 'commons.solr.extras.icu'
bundle that embeds the lucene/solr ICU modules. This new module would require
the com.ibm.icu dependencies and the commons.solr.core module would no longer
depend on ICU.
The reasons why there are optional dependencies are
1. that at the time I created the commons.solr.core module the ability to have
commons.solr.extra.** modules was not yet there
2. for some dependencies (e.g. velocity) it was not possible to separate them
to optional modules (at least with Solr 3.2)
> Missing OSGi configuration for updated Solr commons core
> --------------------------------------------------------
>
> Key: STANBOL-1000
> URL: https://issues.apache.org/jira/browse/STANBOL-1000
> Project: Stanbol
> Issue Type: Bug
> Components: Commons
> Reporter: Tommaso Teofili
> Assignee: Tommaso Teofili
>
> When trying to run commons.solr.core bundle in a custom environment the
> following missing packages show up (apart from the optional):
> com.ibm.icu.lang -- Cannot be resolved
> com.ibm.icu.text -- Cannot be resolved
> com.ibm.icu.util -- Cannot be resolved
> com.spatial4j.core.context -- Cannot be resolved
> com.spatial4j.core.distance -- Cannot be resolved
> com.spatial4j.core.exception -- Cannot be resolved
> com.spatial4j.core.io -- Cannot be resolved
> com.spatial4j.core.shape -- Cannot be resolved
> com.sun.management -- Cannot be resolved
> org.apache.commons.cli,version=[1.2.0,2) -- Cannot be resolved
> org.apache.commons.codec.binary,version=[1.7.0,2) -- Cannot be resolved
> org.apache.commons.lang,version=[2.6.0,3) -- Cannot be resolved
> org.apache.regexp -- Cannot be resolved
> so I think that basically we should add most of them (excluding commons-xyz)
> with an optional resolution in the Import-Package directive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira