Hi Tatu,

Thanks for getting back. I also wanted to follow up creating an issue/PRs, 
but did not get around to do it. It's done now: 
https://github.com/FasterXML/jackson-databind/issues/2726

Let me know if there are further questions or if I can help with anything. 
I am certainly happy to test any changes with Gradle. It's probably the 
easiest to further discuss on the issue.

Regards,
Jendrik

On Thursday, May 7, 2020 at 12:44:52 AM UTC+2, Tatu Saloranta wrote:
>
> On Wed, Feb 26, 2020 at 1:43 PM Jendrik Johannes <[email protected] 
> <javascript:>> 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] <javascript:>.
>> 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/89124e92-3324-4702-b907-cc5eb97bbf31%40googlegroups.com.

Reply via email to