[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
