[jsr-353] Add apache karaf features to jackson #1
Comments
…ckson-datatype-jsr353 (#12)
…ckson-datatype-jsr353 (#12)
cowtowncoder
changed the title
|
Would be eligible for Hacktoberfest swag for sure. |
|
@cowtowncoder If so, what version of jackson should be targeted? And what's the timeline? I.e. when do something participating in Hacktoberfest need to be ready? |
|
@steinarb Hacktoberfest is for October 2020; does not actually have to be merged during it, I think I can just add a label to indicate acceptance (merging would indicate acceptance too). Depending on timeline: right now, 2.12 is still possible (rc1 to be released Really Soon Now, but final 2.12.0 at least 4 weeks out I think). If not, once I create 2.13 branch, that. |
|
>>>> Tatu Saloranta ***@***.***>:
If changes are minor enough could even go in 2.12 patch release, I forget if there was something invasive needed or not.
The invasive change is changing dependencies to <provided> (to make the
bundle-maven-plugin and maven-karaf-plugin do the right thing) and that
will break build that relies on transitive dependencies.
|
|
@steinarb is that specifically just for this repo (wrt dependency to jsr-353 impl) or... ? For such cases, definitely for 2.12 then and not patch. But I guess it really depends on which dependencies would become provided. |
|
@cowtowncoder The change to maven provided was in several repos, and also in the core repos (I think) which has build effects for more or less all projects. I have all of the changes in my notes somewhere, but not handy right now. (The build fix for a build that breaks because of this change, is to explicitly add all maven dependencies that are needed. So the fix is straightforward) |
|
@steinarb Ok I am just trying to understand need for "provided" dependencies since that's different from some of other transitive dependencies (compile-time, mostly). |
|
@cowtowncoder To the maven-bundle-plugin provided means "add an import-package in the manifest.mf rather than pulling in the packages into the bundle" To the karaf-maven-plugin provided means: "do not add this dependency as a bundle that should be started by the feature". Instead a feature dependency is added for a feature that will start the bundle. Karaf features is a higher level dependency mechanism that figures out what needs to be loaded (and more importantly what does not need to be loaded) and avoids starting bundles multiple times (instead already started bundles are shared). It is possible to work around not changing but that would require a lot of maven configuration, that is fragile wrt. to code changes. The short story is that when working with OSGi and maven it is best to have dependencies as provided. However having dependencies as provided has the effect that maven won't use transitive dependencies when compiling. That's where the "changes to builds" comes in: builds that currently rely on transitive dependencies will start failing when scope is changed. The fix will be fairly trivial: add the missing dependencies as direct dependencies. But people whose build break may be annoyed. |
|
Hmmh ok. I feel I am still missing something... so just make sure:
To take a concrete example: |
|
The answer to the first question is: Yes. with "provided" we are talking about the scope of maven dependencies. The answer to the second question, is: Yes, there is value in starting at the bottom and creating features for the core features. However, the core features are where the scope of maven dependencies have to be modified. I.e. that's where the change to maven builds occur. And once the core dependencies are in place creating other features on top of them are easy. |
|
(FWIW just adding the features for the jackson core will have value for me personally, because those are the features I need for a feature for loading jersey) |
|
@cowtowncoder I was too tired to see the last question: what projects are effected? I have a list somewhere of the affected projects. I will dig it up this afternoon (European time), and post it here. |
|
@cowtowncoder These are the maven dependency changes:
|
|
Ok, unfortunately, if "provided" is scope for Maven build, I don't think I will want to proceed with this. |
|
I'm sorry to hear that. It means a lot of work will be wasted. And it really was a lot of work. FWIW I think the maven build is more consistent and predictable after the change. Before some dependencies had scope provided and some had scope compile (ie. the default when no ). With this change they are provided for a reason, (but it shouldn't be a candidate for a minor version. It could be a candidate for a major version that will break builds in any case...?) |
|
I am sorry that I did not catch this earlier, to indicate that this can not proceed. I do not think there were many provided dependencies ever, with maybe exception of JAXB classes for JAX-RS provider or such. But I can not see any reason why transitive dependencies should not be properly brought in so that -- for example -- when user uses API of (*) dependency was shaded earlier, but them OSGi users complained that this causes some issues. Go figure. |
This is the part of FasterXML/jackson-databind#2434 that relates to changes to the jackson-datatype-jsr353 project.
The text was updated successfully, but these errors were encountered: