Steve Rowe created LUCENE-5257:
----------------------------------
Summary: 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
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]
