-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
I haven't, until now.
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. |
@deejay1 @cowtowncoder Are you reading this? Opinions? Thoughts? |
I would be happy to integrate this module as part of 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 agree that inclusion in one of "official" Jackson repos might mostly help wrt visibility and perhaps help with version releases and compatibility. https://github.com/FasterXML/jackson/ for what that is worth. Does that make sense? |
Sounds good
Would be nice, if take a deeper look to make sure whether it's a good fit, especially from architecture and API design perspective.
Is Jackson following SemVer? If yes, how strictly?
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). (*) 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: and we can collaborate on possibly merging this into |
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 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 |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: