[jira] [Resolved] (LUCENE-5257) Lock down centralized versioning of ivy dependencies

["Steve Rowe (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Rowe resolved LUCENE-5257.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 4.6
                   5.0

Committed to trunk and branch_4x.

> Lock down centralized versioning of ivy dependencies
> ----------------------------------------------------
>
>                 Key: LUCENE-5257
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5257
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Steve Rowe
>            Assignee: Steve Rowe
>            Priority: Minor
>             Fix For: 5.0, 4.6
>
>         Attachments: LUCENE-5257.patch, LUCENE-5257.patch, LUCENE-5257.patch
>
>
> 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:
> {noformat}
>   <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
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org