[
https://issues.apache.org/jira/browse/LUCENE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: [email protected]
For additional commands, e-mail: [email protected]
