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/CAL4a10hjSPFmRYp-W4sm2FH0msQto1de6rqH7VsCxZaKu%3Di9ng%40mail.gmail.com.
