On Saturday, February 8, 2020 at 12:32:50 AM UTC+1, Tatu Saloranta wrote:
>
> > In your case, it would probably be good to have a Maven plugin that
> generates, or enriches, a GMM file with the dependency information from the
> POMs.
>
> Yes.
>
If we get to a conclusion about a doable approach below, I can have a look
into providing this.
>
> > 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.
> > A variation of the approach works BOM. Then, components declare what we
> call dependency constraints directly in their metadata.
> > For example, this could be done for the core components only (if they
> are released together):
> >
> > jackson-core-2.10.2.module { dependency-constraints {
> jackson-databind:2.10.2, jackson-annotations:2.10.2, } }
> > jackson-databind-2.10.2-module { dependency-constraints {
> jackson-core:2.10.2, jackson-annotations:2.10.2, } }
> > jackson-annotations-2.10.2.module { dependency-constraints {
> jackson-core:2.10.2, jackson-databind:2.10.2, } }
> >
> > This means that if you select `2.10.2` for any of the three components,
> `2.10.2` will also be selected for the other two (through a constraint
> directly defined in the metadata).
> > This could maybe work?
>
> Jackson 3.0 will change versioning slightly, dropping patch from
> annotations (there will only be 3.0, 3.1, unless some critical problem
> were found requiring patch version), which might complicate this in
> that annotations would only limit minor version of other components.
>
This is not be a problem. The versions do not have to be the same. As long
as we know "what fits together".
Jendrik
--
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/edef900a-fa2e-4413-9b03-82461f106e90%40googlegroups.com.
