[ 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 New patch with a few changes: * Added orphan checking for {{/org/name}} coordinate keys in {{ivy-versions.properties}} file that are not referred to in any {{ivy.xml}} file. * In order to add orphan checking, I had to make the task run only at the top level, so that it sees all the {{ivy.xml}} files across the whole project. The simplest way to do that with the current build was to place the {{check-lib-versions}} target in {{lucene/build.xml}}, and then invoke it from the top-level {{validate}} target, recursively checking the {{ivy.xml}} files in the parent of the {{lucene/}} directory. (This is a little clunky - really it should live at the top level - but I can live with it.) * Cleaned up the {{ivy-versions.properties}} file, so that versions shared by two or more libs are represented as a property named for their org/groupId (and sometimes part of their name/artifactId if the org/groupId didn't seem to be sufficiently differentiating). I'll commit later today if there are no objections. > 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-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