You are making a mountain out of a mole hill. If a plugin released for 2.8.2 doesn’t work with 2.11.0 we are doing something wrong. Users shouldn’t need to inspect anything.
The problem with your premise is assuming these components require some specific version of log4j-core. Ralph > On Jan 22, 2018, at 5:10 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Mon, Jan 22, 2018 at 4:45 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> >> >>> On Jan 22, 2018, at 4:26 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >>> >>> On Mon, Jan 22, 2018 at 4:22 PM, Ralph Goers <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> >>> wrote: >>>> >>>> That process would be guaranteed to have things messed up and would make >>>> users wonder why versions of jars were skipped. >>>> >>> >>> How is that different than having some jars produced out of another repo >>> and not releasing from that repo? >> >> Every repo follows its own versioning scheme and is consistent with >> itself. When you have a chart like Maven does users can easily deal with >> figuring out what versions they want to use. >> > > I'm sorry but this does not make sense to me > > "Every repo follows its own versioning scheme." > > That's part of the problem. When I produce jar version 2.0 out of some > other repo, how do I know what version of Log4j it matches? By its POM > dependency, right? So let's say I have a customer's stack that looks like > this: > - log4j-foo 1.2.3 depends on log4j-core 2.8.2 > - log4j-bar 3.2.1 depends on log4j-core 2.11.0 > > Result: You end up with multiple log4-core jar files on your class path > a.k.a Jar hell. The top level app build is now required to force a specific > version, and exclude the rest, clearly not a selling point for Log4j. > > Because all of our 'extra' plugins (JMS, JDBC, MongoDB, Flume, and so) > depend deeply on a specific log4j-core version, I am now at great risk of > not being able to assemble a working stack. > > The chance of jar hell is greatly reduced if all the plugins come out with > the same version: you know they all match up. > > "When you have a chart like Maven does users can easily deal with figuring > out what versions they want to use." > > That makes no sense to me either: The page https://maven.apache.org/plugins/ > is just a list of plugins and their latest version. That basically tells me > the same thing as mvn > versions:display-dependency-updates|display-plugin-updates. How does that > help picking version x vs. y? > > Sorry to be so negative but I do not see a workable plan that is better > than what we have now. By a long shot :-( But I like that we are hashing > things out. Thank you for that :-) > > Gary > > Gary > > >> >> Ralph >> >>
