Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-5257

Lock down centralized versioning of ivy dependencies

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.6, 6.0
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New

      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
      

        Attachments

        1. LUCENE-5257.patch
          27 kB
          Steve Rowe
        2. LUCENE-5257.patch
          27 kB
          Steve Rowe
        3. LUCENE-5257.patch
          19 kB
          Steve Rowe

          Issue Links

            Activity

              People

              • Assignee:
                steve_rowe Steve Rowe
                Reporter:
                steve_rowe Steve Rowe
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: