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 > <https://groups.google.com/d/msgid/jackson-user/3992e8f9-0e0b-4cf3-b3a6-2ed7dde22882%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGrxA27%2BA7i5Ezbzv1Cj3LpHsx-K2wNqu1y%3DUR2ryVz%3D5SRrZg%40mail.gmail.com.
