It would be nice if jackson had native karaf features #2434
Comments
|
See also eclipse-ee4j/jersey#4191 (which hasn't received much interest since it was opened on July 5 2019). |
|
@steinarb Improvements to OSGi metadata sound like a good improvement, so PR would be nice, would be happy to help merge. The only (?) limitation is that there shouldn't be new runtime dependencies; I assume only Maven build plug-ins are needed. At this point changes should probably go against |
|
@cowtowncoder No new runtime dependencies will be introduced, only a build dependency to the karaf-maven-plugin. XML files will be created and added to the jar artifacts. I will work on a PR for the 2.10 branch |
|
@steinarb Excellent, sounds good. I am hoping to publish 2.10.0.pr2 quite soon, but will probably wait until early next week. If PR makes it in by then (I'll be out for the weekend but will have time before release), good, if not, there's still some time between that in final 2.10.0. |
|
@cowtowncoder What projects/repos will be affected by, and included in, the 2.10 release? I assume jackson-core, but which others? The ones in the jackson-bom? Is there a master POM where it is possible to put <pluginManagement> configurations? |
|
Answering my own question, looking at https://github.com/FasterXML/jackson#active-jackson-projects I think that the repos that I need to fork and create PR in, are:
@cowtowncoder This was a lot of repos to fork and modify, so I have a feeling that I may have promised more than I can keep, especially with the 2.10 target. But I will try! :-) |
|
Yes, that looks like most things. No need to do
Now: now worries about 2.10.0. We'll do what we can. I did push 2.10.0.pr2 already, just because I figure that gives more time for other testing. |
|
@cowtowncoder The following repos had problems, so I'm focusing on the others (including the ones you listed in the previous comments): Note: I haven't investigated any of the build errors mentioned below. I just did a quick "mvn clean install" to get a baseline before doing the changes.
|
|
@cowtowncoder Looks like I need to add oss-parent to the list. That's where the configuration of maven-bundle-plugin resides, and it would be natural to put the karaf-maven-plugin next to it (that's what I've done in my own projects). Or should I put the configuration into jackson-parent? oss-parent is not versioned as often as jackson proper, and has no 2.10 branch. I guess I go for jackson-parent for now, unless I hear something else. |
|
Another complication: jackson-parent has a fixed version 2.10.pr2 rather than a SNAPSHOT version, so I can't modify it (the version from maven central is used instead). I guess I can move it down into jackson-base, and replicate the configuration in jackson-annotation...? |
|
@cowtowncoder I think it would be best to make these changes to something with SNAPSHOT versions, so I think I will have to abort these changes and move them to master instead (or whatever branch is most appropriate. There are two reasons for this:
|
|
@cowtowncoder FYI I'm still working on a pr against 2.10. I had to change the properties in the jackson-bom pom to snapshot version numbers, and change some parent numbers to the current snapshot on the 2.10 branch, to make the build work. (But don't wait for me, I can move to master if I miss the 2.10 train) |
|
@steinarb for now, 2.10 is fine; there's a chance there will also be 2.11, and if so, that will be similar to 2.10. |
|
@cowtowncoder Ok, I will move on to the 2.11 branch if I can't reach 2.10. |
|
@cowtowncoder Problem in jackson-dataformats-binary/avro/:
Not sure what to do with this except maybe try to upgrade the avro dependency....? There are two versions that follow the currently used 1.8.2: 1.9.0 and 1.9.1 Edit: I tried avro 1.9.1 but it still required code from org.codehaus.jackson Edit2: it does look like avro has been changed to use jackson 2.x and the fix version for 2.x var avro 1.9.0 The compilation errors comes from the jackson avro code. Edit3: I made a new issue for this https://github.com/FasterXML/jackson-databind/issues/2447 |
|
@steinarb Yes, this is a known issue. Alas, Avro 1.9.x has serious problems from our perspective, so attempts at upgrade where and are unsuccessful. So 2.10 will not upgrade to it, as things are. There is an issue tracking this: FasterXML/jackson-dataformats-binary#167 and I'll add a note to the new issue. |
|
@cowtowncoder Ok. Three possibilities:
I think 3 is the least intrusive (need to exclude the jackson 1.9.13 dependencies from the avro dependency, add the jackson 1.9.13 dependencies directly as provided dependencies (so that stuff still will compile), and then add the jackson 1.9.13 jars as runtime dependencies of the feature), so I will try that (but 2.11 is looking as the most likely target for the PRs...:-) ) |
|
@cowtowncoder A question: should this issue be split up into one issue per repo, so that the PRs and the commits in the PRs can refer the issues correctly? (ref the dup issue I made about avro) |
|
Ok, so, I think I would not want to try (2) since shading can get tricky for transitive deps -- although, come to think of it, maybe shading of Apache Avro lib would make sense... it being intended as private internal thing. Except that it being visible it may not be practical approach. (3) seems doable, but my main concern would be that whatever changes are made would also work with Java 9 module system. I know choice of dependency can have effect there, even if we are not generating On issues, yes, I think one per repo makes sense. |
|
@steinarb I created 2.11 branch for Aside from these 4, are there still gaps? Scala module might not yet have |
|
@cowtowncoder A status update: I have rebased all my fix branches on 2.11 (and master where appropriate, version 2.11.0-SNAPHOT in all cases). I made the changes available for review by the head karaf maintainer: http://mail-archives.apache.org/mod_mbox/karaf-user/201910.mbox/browser |
|
@steinarb That sounds good. Thank you for the update! |
|
Hey, I spotted this issue on karaf mailing lists and it would be nice to push this integration out. I've been maintaining a third party repo for that https://github.com/code-house/karaf-jackson for lst couple of years. |
|
@splatch I'm waiting for the karaf head maintainer to complete his review of my branches (he's a very busy man). And after that I need to rebase the changes on whatever is the current maintenance branch for each module. |
|
What is the current status of this? Is the karaf features ready? |
|
I'm still waiting for the code review, and had basically forgotten about the whole thing. I can submit what I have without the code review if it is of interest. I would need to move all of the changes to newer branches. Main issue with my changes: I have changed many inter-module dependencies from compile to provided, and this has effect for non-OSGi applications as well: maven builds that have relied on transitive dependencies will need to add explicit dependencies to all jackson modules. It would be good to know if this is a deal breaker before I move the changes to a newer branch. The reason for the change is to have maven-bundle-plugin and karaf-maven-plugin do the right thing. |
|
It'd be good to have an idea of what dependencies were changed, as it is difficult to say much without more details. Some changes could be fine. Another question I had was this: is there any value in incremental changes? For example, rolling out needed changes to core pieces (streaming (jackson-core), jackson-annotations, jackson-databind) first. |
|
I have a summary of the changes somewhere and will try to dig it up. FWIW just doing the three you mention has value for me personally, because those are the ones I personally use and are the ones that Jersey uses (together with perhaps a few others such as extended date parsing). |
Summary of the changes with link to issue, branch and description of the changes below.
To be concrete, the important ones to me, are:
To make the changes ready to merge, I
Anyway, here are the summary of changes:
|
Apache karaf features are used by Apache karaf to load runtime dependencies.
When using features karaf is very clever at finding and correctly loading run-time dependencies. The startup problems familiar to developers of OSGi applications are a non-issue when using karaf features to load the applications.
A manually created third party jackson karaf feature exist https://github.com/Code-House/karaf-jackson but that feature isn't actively maintained (last commit was one year ago for jackson 2.8.11). I also have a feature loading some jackson artifacts in my jersey karaf feature https://github.com/steinarb/jersey-karaf-feature (which I will happily abandon if jackson and jersey start providing their own karaf features).
Using the karaf-maven-plugin it is possible to piggyback the creation of karaf features during the regular build. I.e. the features would be created and released with jackson.
The artifacts created by the karaf-maven-plugin consists of attachments with classifier features and type xml to the jar file/OSGi bundle artifacts.
In addition to the feature file attachment of the karaf-maven-plugin, for my own projects, I usually create a semi-manual features.xml file attachment to the top pom, that aggregates all of the feature files of the jar files/OSGi bundle projects. This means I only need to load a single feature file to have all of the features available.
If there is interest in having a jackson karaf feature (or actually: set of features), I can provide a pull request.
The text was updated successfully, but these errors were encountered: