Any plans to contribute to Jackson-datatypes-misc?
keilw opened this issue · 14 comments
I know, at some point the Zalando extension module for BeanValidation and JavaMoney was contributed to Hibernate Validator, do you consider something similar with the https://github.com/FasterXML/jackson-datatypes-misc repository that offers e.g. bindings for JodaMoney (not as powerful as JSR 354, e.g. limited conversion with a complete lack of conversion providers) or is there a reason like licensing that won't allow this here?
do you consider something similar
I haven't, until now.
is there a reason like licensing that won't allow this here?
Not that I'm aware of, no.
I'm not opposed to this, but curious. In contrast to the bean validation support for JavaMoney (which was added as an optional piece directly to the hibernate validator core), what's the immediate benefit? It would still live as a separate module with its own lifecycle, similar as it does right now, doesn't it? The only difference being that it would be located under the FasterXML/Jackson umbrella (i.e. org) which might give it a more official blessing. Anything else?
And, not to forget, what about the maintenance burden. Who would own and maintain that module? I don't mind gifting it to someone, if I have less code to maintain.
Could you ask the contributors to https://github.com/FasterXML/jackson-datatypes-misc @deejay1 and @cowtowncoder what they think about it.
Similar to your input the JodaMoney support could have been done by the Joda committer(s) at Joda.org, but it wasn't, so I guess the authors of https://github.com/FasterXML/jackson-datatypes-misc decided to take ownership here.
If they wold be happy to maintain it, you might have less effort.
@deejay1 @cowtowncoder Are you reading this? Opinions? Thoughts?
I would be happy to integrate this module as part of jackson-datatypes-misc repo, if everyone agrees it makes sense. From quick look at README here (but not checked code), it seems like a good fit.
The way ownership works would be such that original owners would still more or less own the module, but what I (or more generally Jackson core team which at this point mostly means me anyway) would do would be to handle releases of new versions as part of default Jackson version flow -- this just means that there will be new version of all components at same time. I would also help with changes needed wrt Jackson api changes, upgrade method calls in cases some methods deprecated and so on.
I also try to help integrate with newer features, but usually would need help from the owners as well.
I will grant full committer access to all owners so that they can interact with the module the way they want.
I agree that inclusion in one of "official" Jackson repos might mostly help wrt visibility and perhaps help with version releases and compatibility.
This module is already listed on:
https://github.com/FasterXML/jackson/
for what that is worth.
Does that make sense?
I would be happy to integrate this module as part of
jackson-datatypes-miscrepo, if everyone agrees it makes sense.
Sounds good
From quick look at README here (but not checked code), it seems like a good fit.
Would be nice, if take a deeper look to make sure whether it's a good fit, especially from architecture and API design perspective.
this just means that there will be new version of all components at same time. I would also help with changes needed wrt Jackson api changes
Is Jackson following SemVer? If yes, how strictly?
I also try to help integrate with newer features, but usually would need help from the owners as well.
I will grant full committer access to all owners so that they can interact with the module the way they want.
Sounds like my preferred approach. Great!
Jackson does follow SemVer regarding its public-facing API, so typical user code written for given 2.x version should keep working for later ones. 1.x and 2.x lived in different Java packages (and Maven artifacts) so they can co-exist without interfering.
But some of internal interfaces need to evolve at faster rate (*), especially ones that are based on sub-classing, so that Jackson components are only guaranteed to work with matching minor versions (usually components do work with other combinations too, but there is order -- components higher up in stack, like datatypes, require same-or-newer version of lower-level dependencies like jackson-databind and jackson-core).
Having said above, effort is made to minimize incompatible changes to internal extensions points too, using deprecation markers; this works for most changes.
(*) or put differently, if major version bump was required for all internal extension point changes, Jackson major version would typically be bumped for all current minor versions -- and this would be a major problem with frameworks like Spring Boot.
I will add link to this issue on my wiki TODO page:
https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress
and we can collaborate on possibly merging this into jackson-datatypes-misc. I think it could make it into 2.12.0 release if all goes well, and that would seem like a clean cut-off point.
I'd be happy to help either with PR or otherwise, given I am currently the most active Maintenance Lead of JSR 354.
@keilw That would be very much appreciated, PR would be against 2.12 branch (I can merge forward to master which is for 3.0.0-SNAPSHOT). I would need CLAs from you and @whiskeysierra I think:
https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf
before merge (simplest way is to print the doc, fill & sign, scan/photo, send to info at fasterxml dot com) but there is no hurry for that.
Quick note: as per above note: I created a separate issue on target repo, in case someone wants to work on technical aspects of moving this over -- mostly to find relatively easy things for Hacktoberfest participants to tackle.
If anyone is already working on this, please just add a note on that issue.
@otrosien I'm in no position to make this call (anymore?) since I'm no longer working @zalando.
Somebody with authority needs to make a call here.
@cowtowncoder In case this is being greenlit, I'd be open to contribute to it.
Ok, sorry to hear that. But I hope someone from @zalando might be able to follow up on this.
Alternatively, a separate implementation would probably be doable if anyone wanted to start from scratch.
I will bring it up in the community and come back.