Ok. By the way, in the process of doing this I was able to resolve ALL dependency convergence issues in the dependency convergence reports.
Nick On May 16, 2013, at 1:18 PM, Ralph Goers wrote: > Well, if they changed the package names so there is no conflict then I guess > we will have to have both versions. > > Ralph > > On May 16, 2013, at 11:07 AM, Nick Williams wrote: > >> It's not just the groupId/artifactId that changed between Jackson 1 and >> Jackson 2. It's the Java package, too. Simply excluding Flume's dependency >> on 1.x and introducing a dependency on 2.x doesn't work. Flume classes >> literally don't load due to NoClassDefFound errors. >> >> N >> >> On May 16, 2013, at 1:04 PM, Ralph Goers wrote: >> >>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
