[
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: [email protected]
For additional commands, e-mail: [email protected]
