[ https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Rowe updated LUCENE-5257: ------------------------------- Attachment: LUCENE-5257.patch Patch implementing the idea as a custom Ant task: {{LibVersionCheckTask}}. I had originally planned a scripted implementation, but I figured that could fail for valid {{ivy-version.properties}} syntax, or valid {{ivy.xml}} syntax, since a script would likely make assumptions about the format, so I went with full parsing for both, though I had to write the Properties file parser, since {{java.util.Properties}} doesn't provide file-order access to the parsed contents. The new task checks the {{/org/name}} keys in the centralized versions file for lexical sort order and for duplicates, then verifies that the {{rev}} attributes for all {{<dependency>}}-s in all {{ivy.xml}} files in the current directory ({{lucene/}} and {{solr/}}) and below are formatted in {{$\{/org/name}}} format, where {{org}} matches the value of the "org" attribute, and {{name}} matches the value of the "name" attribute. I modeled it on (and stole a lot of it from) the custom {{LicenseCheckTask}}. The patch includes a fix to the {{ivy-versions.properties}} file that the new task found: there are currently duplicate property keys for two of the httpcomponents jars. Like {{LicenseCheckTask}}, I made it run with the {{validate}} target, so it'll be included with {{ant precommit}}. Run alone, it took less than a tenth of second in each of {{lucene/}} and {{solr/}} on my machine. I think it's ready to go. > 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-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