On Thu, Feb 6, 2020 at 2:15 AM Jendrik Johannes <[email protected]> wrote:
>
> Hi Tatu,
>
> Thanks for your interest!
>
>>
>>>
>>> Maybe the following blog post about version alignment by using a BOM (with
>>> Gradle 6), is of interest for some who use Jackson in Gradle builds. It
>>> uses Jackson, and the Jackson BOM, as an example:
>>>
>>> https://blog.gradle.org/alignment-with-gradle-module-metadata
>>
>>
>> Very interesting. Will need read with thought.Thank you for sharing this.
>
>
> Let me know if you have any questions.
>
>>>
>>> From what I see about how Jackson is published, I realize that it is not
>>> easy to actually publish this additional metadata for future versions.
>>> (Although, for the benefit of Gradle users, it would be a great thing!)
>>>
>>> In any case, I want to offer support from the Gradle side if there should
>>> be interest in this topic from the Jackson developers. While using Gradle
>>> as build tool makes it easy to publish the additional metadata, it is also
>>> possible to find solutions with Maven builds. We are exploring that, for
>>> example, with Guava's build which has some other interesting use cases
>>> solvable with GMM (https://blog.gradle.org/guava).
>>>
>>>
>> Yes, I think this is an area where we would be interested in finding
>> improvements.
>> It is probably true that on short term it may be challenging to provide
>> metadata, but at the same time Jackson is producing some metadata using
>> non-native tooling:
>>
>> - OSGi metadata has been generated with Felix plug-in for years now (and
>> mostly works, although project relies on OSGi users to report issues as
>> tooling can only verify some problems)
>> - Java 9+ module info is generated using Moditect plug-in since JDK tooling
>> only available on JDK 9 and later (which won't work too well for producing
>> versions usable on Java 8 and earlier)
>>
>> so perhaps there could be a way to include some more information even if
>> build itself uses Maven.
>
>
> Good to know about the other metadata you publish. I wasn't aware of that.
> Technically, it is not a problem to publish Gradle Module Metadata (GMM) with
> Maven. The metadata file itself is following Maven naming conventions and can
> as such be treated as an additional artifact when publishing with Maven (I
> have done a poc using the "build-helper-maven-plugin" on the Guava build
> here). In that example, the GMM file is maintained manually in parallel to
> the POM.
>
> 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.
> 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.
> 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.
-+ 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/CAL4a10jjfvD9UShb-TfWdbfU0iJKfi72U88nqHHKRCLLzHKchg%40mail.gmail.com.
