No real preference. I haven't done a strict comparison, but I think both
are largely identical. The only difference I recall is that Jochen's is
published under his own group id.
On Tue, Nov 1, 2016 at 3:38 PM Tatu Saloranta <[email protected]> wrote:

> 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.
>

-- 
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.

Reply via email to