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
