[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786425#comment-13786425
]
ASF subversion and git services commented on LUCENE-5257:
-
Commit 1529243 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1529243 ]
LUCENE-5257: Lock down centralized versioning of ivy dependencies
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
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786438#comment-13786438
]
ASF subversion and git services commented on LUCENE-5257:
-
Commit 1529246 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1529246 ]
LUCENE-5257: Fix top-level validate target subant invocation syntax
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
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786458#comment-13786458
]
ASF subversion and git services commented on LUCENE-5257:
-
Commit 1529248 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1529248 ]
LUCENE-5257: Lock down centralized versioning of ivy dependencies (merged trunk
r1529243 and r1529246)
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
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786463#comment-13786463
]
ASF subversion and git services commented on LUCENE-5257:
-
Commit 1529249 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1529249 ]
LUCENE-5257: merge CHANGES.txt entry with LUCENE-5249's entry
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
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784229#comment-13784229
]
Robert Muir commented on LUCENE-5257:
-
{quote}
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.
{quote}
Not a chance. -1 to jar hell.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784266#comment-13784266
]
Steve Rowe commented on LUCENE-5257:
bq. Not a chance. -1 to jar hell.
Cool, makes this issue easier.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784328#comment-13784328
]
Hoss Man commented on LUCENE-5257:
--
FWIW: the idea that we _might_ down the road want to allow moduleA to depends
on third-party-2.0.jar while unrelated moduleB depends on third-party-3.0.jar
came from a mental exercise of if we lock this down with a build failure now,
how will we deal with it if we decide we want to allow it in some special case
later?
but i agree: even if moduleA and moduleB have no dependencies on eachother, and
no other moduleC exists that depends on both moduleA and moduleB it's still a
bad idea to let moduleA and moduleB depend on diff versions of third-party.jar
since some downstream client of lucene/solr might want to use both moduleA and
moduleB.
more importantly: we can lock this down with a build failure now, and if we do
ever change out mind, we have an idea here of how to tweak the rules to allow
special exceptions in a way that's non-sneaky and really obvious ... but unless
someone is clamoring for it, i say we help our users avoid classpath hell just
as much as we want to.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784349#comment-13784349
]
Robert Muir commented on LUCENE-5257:
-
Let me clarify what i mean by jar hell:
if we want to add exceptions because someone jacked up their maven coordinates
or some other reason, when in fact its not jar hell, to me thats different
than declaring we will allow exceptions for jar hell.
For example: some stuff depends on jetty6 (org.mortbay.jetty) and other stuff
depends on jetty8 (org.eclipse.jetty). This isn't jar hell, because the
packages are totally different in the jar files so they don't conflict. They
also renamed the coordinates to org.eclipse.jetty to match.
But i think we shouldnt allow true jar hell (where the stuff inside the jars
conflict). People should be able to pick and choose what stuff they want to use
and use it, and we shouldnt ship a release with jar hell.
I would also like to explore adding a jar hell detector in the future to our
smoketester, that unzips all jar files and fails if e.g. any .class (maybe even
resources outside of META-INF) conflict. I think we should try to improve our
build with checks like this, but if we allow for jar hell exceptions it makes
such a check extremely difficult or impossible.
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
