Christopher, Jochen, any preference on which repo I should fork or copy? I think it'd make sense to get this under FasterXML repo for 2.9, and I might as well do it know. Another reorganization that I am planning to do is to merge Java8 repos (jackson-module-parameter-names, jackson-datatype-jdk8, jackson-datatype-jsr310) under multi-maven module repo -- simply to make release process more efficient, but keeping modules (jars) still separate. They will get merge into databind for 3.x, but I think 2.8 and especially 2.9 will live quite long so there's some benefit.
-+ Tatu +- On Tue, Oct 4, 2016 at 11:01 PM, Tatu Saloranta <[email protected]> wrote: > On Tue, Oct 4, 2016 at 10:35 PM, Christopher Currie <[email protected]> > wrote: >> >> I had not seen that, as it didn't exist last week when I looked for it. It >> appears mostly identical, save for plugin management for which I borrowed >> jackson-parent. > > > Right, I assume it's just convergent evolution, solving the same problem. > >> >> >> AFAICT the release process is straightforward. I don't have an opinion on >> whether other jackson projects use it internally, though that would have the >> nice property of internally validating correctness to a certain extent. >> >> Happy to reparent the project under FasterXML if it ends up useful enough. > > > We could definitely test this with 2.9.0.rc1 and see how it'd fly, and > hopefully then use for 2.9.x itself. I agree in usefulness as sort of > canary. > > It could also (eventually) solve one small -- but to me, personally annoying > :) -- issue wrt `jackson-annotations`: it would be possible to remove patch > version from annotations, without making devs life more difficult. Bom > version would be fully patch-qualified, but eventually there would just be > `jackson-annotations-2.9`, `jackson-annotations-3.0`, with no patch version. > > -+ Tatu +- > > >> >> >> On Tue, Oct 4, 2016 at 10:22 PM Tatu Saloranta <[email protected]> wrote: >>> >>> Interestingly enough this surfaced on Twitter as well, so there's also: >>> >>> https://github.com/joschi/jackson-bom >>> >>> which I assume is about the same thing. >>> So the idea is to usually Maven import this with scope of 'import', to >>> get the versions from dependencyManagement? >>> >>> I am supportive of the idea, assuming release is as simple as just using >>> mvn release plugin, possibly modifying one line (or zero; but I had some >>> issues earlier trying to rely on ${project.version}), and could release this >>> as part of the usual Jackson release process. Or work with whoever would >>> like to maintain it, if preferable. >>> >>> One open question would be whether core Jackson components themselves >>> should use this: I assume that would make sense. There may be some minor >>> question related to inclusion (or not) of components outside of fasterxml, >>> but I think bom could start incorporating more versions whenever (and if) we >>> figure out a way to coordinate releases of external things (like, say, >>> bson4jackson, mongo mappers?) in some sensible way. >>> >>> So... what do others think? Would you find this useful? >>> >>> -+ Tatu +- >>> >>> ps. I think `jackson-parent` can still be used for versions of plugin >>> dependencies. >>> >>> >>> On Tue, Oct 4, 2016 at 7:01 PM, Christopher Currie >>> <[email protected]> wrote: >>>> >>>> A couple of times recently my team has been hit by jackson project >>>> version mismatches, as one or the other project will 'dependencyManage' >>>> only >>>> some modules and not others. I propose to create (and maintain, if needed) >>>> a >>>> 'jackson-bom' project that, similar to the 'dropwizard-bom' project, >>>> provides dependency management across ALL jackson modules. A draft of this >>>> project is here: >>>> >>>> https://github.com/christophercurrie/jackson-bom >>>> >>>> Feedback is encouraged, especially if anyone else would find such a >>>> thing valuable. >>>> >>>> Christopher >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "jackson-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "jackson-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jackson-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
