[ 
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786466#comment-13786466
 ] 

ASF subversion and git services commented on LUCENE-5257:
---------------------------------------------------------

Commit 1529250 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1529250 ]

LUCENE-5257: merge CHANGES.txt entry with LUCENE-5249's entry (merged trunk 
r1529249)

> 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
>         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

Reply via email to