[LUCENE-5257] Lock down centralized versioning of ivy dependencies

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 4.6, 6.0
• Component/s: general/build
• Lucene Fields: New
• Assignee: Steven Rowe
• Reporter: Steven Rowe
• Created: 02/Oct/13 18:09
• Updated: 28/Aug/22 13:54
• Resolved: 04/Oct/13 18:34

Description

LUCENE-5249 introduced centralized versioning of 3rd party dependencies and converted all ivy.xml files across Lucene/Solr to use this scheme. But there is nothing preventing people from ignoring this setup and (intentionally or not) introducing non-centralized dependency versions.

SOLR-3664 discusses the problem of out-of-sync 3rd party dependencies between Lucene/Solr modules. Centralized versioning makes synchronization problems less likely but not impossible.

One fairly simple way to ensure that all modules use the same version of 3rd party deps would be to require that all deps in ivy.xml would have to use the rev="${/org/name}" syntax, via a validation script.

The problem remains that there may eventually be a requirement to use different 3rd party libs in different modules. Any form of lockdown here should allow for this possibility. Hoss's suggestion from a conversation on #lucene IRC earlier today:

  <hoss> perhaps exceptions could be by naming convetion
<sarowe> can you give an example?
  <hoss> ie: variables must match either ${group}/${artifact} or they must match
         /VERSION_MISTMATCH_EXCEPTION/${group}/${artifact}
<sarowe> nice idea
         no external config required
  <hoss> right
         and it has to be real obvious when you are bucking convention
  <hoss> or better yet: ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION
         ... and there is another check that the version file is in ascii order
         so you are garuntted that it has to be right there in the versions file
         one line after ${group}/${artifact}
<sarowe> i like it
  <hoss> no change someone updating ${group}/${artifact} won't notice it
         i suppose really it should be
         ${group}/${artifact}/VERSION_MISTMATCH_EXCEPTION/${reason}
         ... since you might have more then one exception per ${group}/${artifact}
         but now i'm just making things up w/o evn really understanding
         the conventions you've alreay put in place
<sarowe> :)
  <hoss> you get the idea
<sarowe> yes

Issue Links

• is related to: SOLR-3664 risk of inconsistency in solr(contrib)->module->thirdparty dependencies