[
https://issues.apache.org/jira/browse/SOLR-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420372#comment-13420372
]
Hoss Man commented on SOLR-3664:
--------------------------------
Theses are the two areas i know about in which solr has indirect dependencies
on third party packages via lucene modules:
* solr/contrib/uima - depends on:
** lucene/analysis/uima - depends on:
*** ... various uima jars
** ...some other uima jars that lucene/analysis/uima doesn't use
* solr/contrib/analysis-extras - depends on:
** lucene/analysis/icu - depends on:
*** icu4j
** lucene/analysis/smartcn
** lucene/analysis/morfologik - depends on:
*** ... various morfologik jars
** ...etc
(Note: currently these situations are both in solr contribs, but the potential
problem moving forward could also occur in solr/core in the future)
As noted in SOLR-3623, the key reason for this redundancy (as opposed to just
referencing these third party jars in the build.xml the same way we do for
lucene jars) is to ensure that both the third-party jar files, and their
licenses make it into the Solr binary release artifacts.
My initial thought for addressing this was to try and keep things in sync
automatically by specifying that if a solr contrib depends on a lucene module,
it should override the "resolve" target to copy the ivy.xml from the lucene
module, and then delegate to the default "resolve" target -- that way
everything would automatically be in sync. But then I realized that it would
really help in either of the existing situations, where there are multiple
lucene modules whose ivy.xml files would need to be "merged" (analysis-extras),
of extra dependencies would need to be added (uima)
So my current straw man suggestion is this: Solr contribs should continue to
list the third party package dependencies in thier ivy.xml files (redundantly)
but we should remove the corresponding LICENSE/NOTICE/sha1 files from svn and
instead override the "resolve" target to copy all txt/sha1 files from the
lucene modules they depend on.
This wouldn't give us any automated updating of ivy.xml, but any committer who
adds/modifies the dependencies of a lucene module w/o knowing/remembering that
there is a solr ivy.xml files that also needs updated should get a failure when
running "ant clean-jars validate"
It wouldn't be an ideal solution, but it would at least prevent us from
introducing inconsistencies.
(I'm hoping someone else has a better solution)
> risk of inconsistency in solr(contrib)->module->thirdparty dependencies
> -----------------------------------------------------------------------
>
> Key: SOLR-3664
> URL: https://issues.apache.org/jira/browse/SOLR-3664
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> Currently, if something in solr has an indirect dependency on a third-party
> package via a dependency on a lucene module, that is tracked in a
> solr/**/ivy.xml files and redundant copies of the third-party
> LICENSE/NOTICE/jar.sha1 files are committed under solr/**
> This presents a risk that these files may fall out of sync if/when the
> dependencies of the lucene module are updated in the future (ie: a developer
> could update a lucene module to depend on a new package -- or a new version
> of an existing package -- w/o remembering to upgrade the corresponding ivy
> related files in solr)
> we should try to eliminate this risk
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
