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