>
> >> > 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).
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)
--
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.
