Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plans to contribute to Jackson-datatypes-misc? #224

Open
keilw opened this issue Jul 22, 2020 · 14 comments
Open

Any plans to contribute to Jackson-datatypes-misc? #224

keilw opened this issue Jul 22, 2020 · 14 comments

Comments

@keilw
Copy link

keilw commented Jul 22, 2020

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?

@whiskeysierra
Copy link
Collaborator

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.

@keilw
Copy link
Author

keilw commented Aug 6, 2020

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.

@whiskeysierra
Copy link
Collaborator

@deejay1 @cowtowncoder Are you reading this? Opinions? Thoughts?

@cowtowncoder
Copy link

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?

@whiskeysierra
Copy link
Collaborator

I would be happy to integrate this module as part of jackson-datatypes-misc repo, 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!

@cowtowncoder
Copy link

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.

@cowtowncoder
Copy link

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.

@keilw
Copy link
Author

keilw commented Aug 10, 2020

I'd be happy to help either with PR or otherwise, given I am currently the most active Maintenance Lead of JSR 354.

@cowtowncoder
Copy link

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

@cowtowncoder
Copy link

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.

@whiskeysierra
Copy link
Collaborator

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

@cowtowncoder
Copy link

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.

@MALPI
Copy link
Member

MALPI commented Feb 22, 2023

I will bring it up in the community and come back.

@piotrooo
Copy link

@MALPI any news on this?
cc: @zalando

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants