Thank you! I'll have a look, thank you for helping here! -+ Tatu +-
On Mon, May 18, 2020 at 9:36 AM Jendrik Johannes <[email protected]> wrote: > > Hi Tatu, > > Thanks for getting back. I also wanted to follow up creating an issue/PRs, > but did not get around to do it. It's done now: > https://github.com/FasterXML/jackson-databind/issues/2726 > > Let me know if there are further questions or if I can help with anything. I > am certainly happy to test any changes with Gradle. It's probably the easiest > to further discuss on the issue. > > Regards, > Jendrik > > On Thursday, May 7, 2020 at 12:44:52 AM UTC+2, Tatu Saloranta wrote: >> >> On Wed, Feb 26, 2020 at 1:43 PM Jendrik Johannes <[email protected]> wrote: >>> >>> I am about to publish a first version of the plugin. (Have some connection >>> problems right now, but should be done soon.) >>> >>> In theory you could add it to 'jackson-base' as it should be the same for >>> all components: >>> https://github.com/FasterXML/jackson-bom/blob/master/base/pom.xml >>> >> >> I dropped the ball here, but getting back... would you mind filing an issue >> for `jackson-databind`: >> >> https://github.com/FasterXML/jackson-databind/issues >> >> just cut-n-pasting this setting? I think I could get this added for 2.12 >> (just released 2.11.0 last weekend, so can focus on next minor version), >> starting testing now. >> >> -+ Tatu +- >> >> >>> >>> This would be the configuration to add: >>> >>> ------------------------------------------ >>> <plugin> >>> <groupId>de.jjohannes</groupId> >>> <artifactId>gradle-module-metadata-maven-plugin</artifactId> >>> <version>0.1.0-SNAPSHOT</version> >>> <executions> >>> <execution> >>> <goals> >>> <goal>gmm</goal> >>> </goals> >>> </execution> >>> </executions> >>> <configuration> >>> <platformDependencies> >>> <dependency> >>> <groupId>com.fasterxml.jackson</groupId> >>> <artifactId>jackson-bom</artifactId> >>> <version>${project.version}</version> >>> </dependency> >>> </platformDependencies> >>> </configuration> >>> </plugin> >>> ------------------------------------------ >>> >>> Is there some good way to test this locally? Like a script to clone all (or >>> some) repositories and install them? How do you usually test changes to >>> 'jackson-base'? >>> >>> On Wednesday, February 26, 2020 at 6:09:00 PM UTC+1, Jendrik Johannes wrote: >>>> >>>> Hi, >>>> >>>> After discussing this a bit more with my team, I had a look at providing a >>>> Maven plugin for this and here it is: >>>> https://github.com/jjohannes/gradle-module-metadata-maven-plugin >>>> >>>> I am finishing that up and will publish a first version soon. >>>> >>>> What would be the best way to proceed then. Should I try it with all the >>>> Jackson projects that use the BOM and if it works as expected open PRs on >>>> all projects? >>>> >>>> On Tuesday, February 18, 2020 at 10:05:27 PM UTC+1, Tatu Saloranta wrote: >>>>> >>>>> On Tue, Feb 11, 2020 at 9:35 AM Jendrik Johannes <[email protected]> >>>>> wrote: >>>>> >> >>>>> >> >> > The main concern is conceptually with the Jackson release >>>>> >> >> > process. The approach described in the blog post essentially >>>>> >> >> > requires all components and BOM to be released together. Because >>>>> >> >> > the components refer to the BOM and the BOM refers to the >>>>> >> >> > components. If I understand the current release process >>>>> >> >> > correctly, the BOM is published in the end once all components >>>>> >> >> > were released individually. I don't know if that is something you >>>>> >> >> > would consider to do differently in the future? >>>>> >> >> >>>>> >> >> Probably not; while unification of some of projects has been done >>>>> >> >> (and >>>>> >> >> may be done in future), I don't think full mono-repo for all Jackson >>>>> >> >> components is the eventual goal. >>>>> >> >> >>>>> >> >> Typically bom is actually release early in the process, since most >>>>> >> >> components (excluding jackson-annotations and jackson-core that do >>>>> >> >> not >>>>> >> >> depend on any other jackson components) use version set from BOM >>>>> >> >> (that >>>>> >> >> is, extend `jackson-base`, which imports or extends bom). >>>>> >> >> I don't know if this makes much difference. >>>>> >> > >>>>> >> > >>>>> >> > So how does that work exactly? (If there is documentation somewhere >>>>> >> > I missed, please point me to it.) >>>>> >> > Lets take an arbitrary example - "jackson-jaxrs-json-provider". >>>>> >> > When you published "2.10.2", did you publish the BOM before you >>>>> >> > published that module? Because the BOM contains the entry: >>>>> >> > >>>>> >> > <dependency> >>>>> >> > <groupId>com.fasterxml.jackson.jaxrs</groupId> >>>>> >> > <artifactId>jackson-jaxrs-json-provider</artifactId> >>>>> >> > <version>${jackson.version.jaxrs}</version> >>>>> >> > </dependency> >>>>> >> > >>>>> >> > Which is invalid until "jackson-jaxrs-json-provider" is actually >>>>> >> > published. >>>>> >> >>>>> >> Correct in the sense that published BOM is not usable until referenced >>>>> >> versions are accessible. But Maven publishing itself does not care nor >>>>> >> validate it. >>>>> >> So there is a window of opportunity for inconsistent usage. >>>>> >> >>>>> >> At the same time, this does make it possible for Jackson artifacts to >>>>> >> refer to jackson-bom (via jackson-base that extends it, published from >>>>> >> same github repo). >>>>> >> So 2.10.3 version `jackson-datatype-guava`, for example, can use >>>>> >> `jackson-base` 2.10.3 which extends 2.10.3 of `jackson-bom`, which >>>>> >> then provides 2.10.3 version for things it needs (annotations, core, >>>>> >> databind). >>>>> >> >>>>> >> While not exactly minimal amount of work (artifacts do need to update >>>>> >> `jackson-base` dependency version on publishing, in addition to their >>>>> >> own version), this is somewhat better than the way individual >>>>> >> dependencies were increased in the past. >>>>> >> For what that's worth. >>>>> >> >>>>> > >>>>> > Interesting. Thanks for clarifying. So this means that the approach >>>>> > from the blog post would work as the BOM is published *before* the >>>>> > components. >>>>> > >>>>> > Everything would work as expected once all componentss got published >>>>> > for a version. The only 'interesting' situation is while not all >>>>> > componentss are published yet. Then Gradle could end up looking for >>>>> > components that do not exist yet. But maybe that is ok (or even good). >>>>> >>>>> Right. There is a problem wrt lack of atomicity, inherent unless BOM >>>>> itself was used as the "commit", in a way. But given other challenges >>>>> I think it is a workable approach. >>>>> >>>>> > Assume I have a build that depends on "jackson-core" and "LibraryX"; >>>>> > whrere "LibraryX" transitively depends on "jackson-jaxrs-json-provider". >>>>> > >>>>> > Now assume "jackson-core:2.11" has just been published and I update my >>>>> > build to use it. With the BOM dependency, I would then get >>>>> > "jackson-bom:2.11". By that, also the transitive dependency will be >>>>> > upgraded to "jackson-jaxrs-json-provider:2.11" (because there is an >>>>> > entry for that in the BOM). If "jackson-jaxrs-json-provider:2.11" has >>>>> > not been published yet, Gradle will fail trying to find the component. >>>>> > However, this might actually be good: you should not upgrade to "2.11" >>>>> > until all Jackson components you use are available in that version. >>>>> > (If you still want to do take the risk of using potentially >>>>> > incompatible versions, you can add a constraint to your own build to >>>>> > "override" what you get from the BOM) >>>>> >>>>> Yes. >>>>> >>>>> -+ Tatu +- >>>>> >>>>> > >>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> > Groups "jackson-user" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, send >>>>> > an email to [email protected]. >>>>> > To view this discussion on the web visit >>>>> > https://groups.google.com/d/msgid/jackson-user/6a9e9fb5-9653-4589-bf50-f9b901887b36%40googlegroups.com. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "jackson-user" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jackson-user/3992e8f9-0e0b-4cf3-b3a6-2ed7dde22882%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/89124e92-3324-4702-b907-cc5eb97bbf31%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAL4a10ixBp9p6LWNpBS6%2Bru7CRZpvNisJm%3DGPuqPpq8tNb1Q2Q%40mail.gmail.com.
