The master log4j pom.xml should have a version for jackson in the dependency management section. That version should replace any transitive dependencies. However, if the groupId has changed then that doesn't work. You would have to add the Jackson 2 dependencies to flume-ng's pom.xml and exclude the old artifact/groupId.
Note that required transitive dependencies are never obvious just by looking at a pom. Ralph On May 16, 2013, at 10:17 AM, Nick Williams wrote: > So this is all kinds of fun... > > log4j-core depends on: > ....jackson 1.9.11 (optional) > log4j-flume-ng depends on: > ....flume-ng-sdk 1.3.1 depends on: > ........avro 1.7.2 depends on: > ............jackson 1.8.8 > flume-embedded (sample) depends on: > ....flume-ng-sdk 1.3.1 depends on: > ........avro 1.7.2 depends on: > ............jackson 1.8.8 > ....flume-ng-node 1.3.1 depends on: > ........jackson 1.9.3 > > So, we already had three different versions of Jackson in the build: 1.8.8, > 1.9.3, and 1.9.11 ... yuck! > > I took the following steps: > > 1) I upgraded log4j-core's dependency from 1.9.11 to 2.2.1 without any > negative consequences. Everything compiled and all the tests passed. At this > point the dependencies were now 1.8.8, 1.9.3, and 2.2.1. > 2) I used dependency exclusions to exclude 1.8.8 and got it down to just > 1.9.3 and 2.2.1. Everything compiled and all the tests passed. > 3) I tried to eliminate 1.9.3 through a further dependency exclusion, but > log4j-flume-ng classes didn't load anymore. This indicated that Jackson is > NOT an optional dependency of log4j-flume-ng, but instead is a mandatory > dependency, which wasn't obvious the way it was set up. > 4) I kept the 1.9.3 dependency exclusion but added a mandatory 1.9.11 > /runtime/ dependency for log4j-flume-ng. Now everything compiles and all > tests pass again, and the Jackson dependencies are limited to the latest > minor.patch versions of each major version: 1.9.11 (log4j-flume-ng only, > runtime) and 2.2.1 (log4j-core only, compile). > > Ralph said below "I have no problem upgrading to 2.x so long as it works for > both the JSON configuration and Flume." It doesn't work with Flume; Flume > requires 1.x. So as a next step we can either: > > 1) Revert my changes to configuration so that it relies on Jackson 1.9.11 as > well and not on 2.2.1. > 2) Apply my earlier suggestion that we support both 1.9.11 /and/ 2.2.1 or > configuration. > 3) Stick with what we have: 1.9.11 for Flume, 2.2.1 for JSON configuration, > and no more dependency on 1.8.8. > > Nick > > On May 15, 2013, at 7:33 PM, Ralph Goers wrote: > >> I wrote the JSON support just after the ApacheCon in Vancouver, which I >> believe was in 2011. If 2.x was available then it was brand new and the >> documentation was slim. I have no problem upgrading to 2.x so long as it >> works for both the JSON configuration and Flume (I don't think Flume >> actually uses JSON but Avro probably does). Like you, I would prefer not to >> have two versions of Jackson in out build. >> >> Ralph >> >> >> On May 15, 2013, at 11:16 AM, Gary Gregory wrote: >> >>> I would only support the current version: 2.x. >>> >>> Gary >>> >>> >>> On Wed, May 15, 2013 at 2:00 PM, Nick Williams >>> <nicho...@nicholaswilliams.net> wrote: >>> Guys, >>> >>> Background: Since I'm the lead developer on a Jackson Mapper module >>> (https://github.com/FasterXML/jackson-datatype-jsr310), I'm actively >>> involved on their development mailing list. >>> >>> Jackson 1.9 is, well, old. Specifically, 1.9.0 is two years old. 1.9 is the >>> last minor version of the 1.x family. There will continue to be bug fixe >>> releases—for now—about every 4-6 months. The last patch release was in >>> January. >>> >>> Jackson 2.x is the current version with rapid release periods. 2.0 Is about >>> a year old, 2.1 was released in October and 2.2 was released last month. >>> Only major bugs will be fixed in 1.9.x. Minor bug fixes and all new >>> features will go in 2.x. >>> >>> Jackson 1.x and 2.x use different Java packages. This has both advantages >>> and disadvantages. One advantage is that frameworks and libraries, like >>> Spring Framework, can easily support both versions because they can coexist >>> on the same class path during compilation and testing. One disadvantage is >>> that if some library is using 1.x and some other library is using 2.x and >>> you create an application that depends on both libraries, you'll have to >>> pull BOTH versions of Jackson on to your class path. Ugh. >>> >>> Log4j 2 is "brand new" (it's not even released yet). Typically, I would >>> argue that new projects should not use old versions of their dependencies. >>> In Log4j 2's case, I tend to lean the same direction. It doesn't seem wise >>> to tie ourselves to Jackson 1.x so late in its life when Jackson 2.x is >>> already mature and Log4j 2 isn't even released yet. As a Java 8, Spring 4, >>> Jackson 2 user, I know I wouldn't love having to also have Jackson 1 on my >>> class path (if I were using JSON configuration). >>> >>> I would suggest that we should either support both or we should only >>> support 2.x, but only supporting 1.x feels wrong to me. >>> >>> Supporting both wouldn't be a major challenge. The way Spring does it is to >>> have two Jackson* classes and Jackson2* classes with identical APIs. >>> Depending on which version you are already using, you use the appropriate >>> class. In this case, I would approach it like this: >>> >>> - Rename JSONConfiguration to Jackson1JSONConfiguration, and (using >>> CheckStyle's import control) ensure that only this class imports Jackson 1.x >>> - Create a similar class named Jackson2JSONConfiguration, and ensure that >>> only this class imports Jackson 2.x >>> - Alter JSONConfigurationFactory to detect which version is on the class >>> path and return the appropriate JSON configuration, preferring 2.x if both >>> are on the class path >>> >>> Thoughts? >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
