[jira] [Updated] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
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
[jira] [Updated] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
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 with cosmetic cleanups and a CHANGES.txt 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] [Updated] (LUCENE-5257) Lock down centralized versioning of ivy dependencies
[
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
