On an unrelated note, I found a blocker bug related to upgrades from 3.6 (and earlier) to 3.7.
The JIRA is here: https://issues.apache.org/jira/browse/KAFKA-16094 Fix here: https://github.com/apache/kafka/pull/15153 best, Colin On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote: > Hi Ismael, > > I wasn't aware of that. If we are required to publish all modules, then > this is working as intended. > > I am a bit curious if we've discussed why we need to publish the server > modules to Sonatype. Is there a discussion about the pros and cons of > this somewhere? > > regards, > Colin > > On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote: >> All modules are published to Sonatype - that's a requirement. You may be >> missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`. >> >> Ismael >> >> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe <cmcc...@apache.org> wrote: >> >>> Hi Ismael, >>> >>> It seems like both the metadata gradle module and the server-common module >>> are getting published to Sonatype as separate artifacts, unless I'm >>> misunderstanding something. Example: >>> >>> https://central.sonatype.com/search?q=kafka-server-common >>> >>> I don't see kafka-core getting published, but maybe other private >>> server-side gradle modules are getting published. >>> >>> This seems bad. Is there a reason to publish modules that are only used by >>> the server on Sonatype? >>> >>> best, >>> Colin >>> >>> >>> On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote: >>> > Hi Colin, >>> > >>> > I think you may have misunderstood what they mean by gradle metadata - >>> it's >>> > not the Kafka metadata module. >>> > >>> > Ismael >>> > >>> > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe <cmcc...@apache.org> wrote: >>> > >>> >> Oops, hit send too soon. I see that #15127 was already merged. So we >>> >> should no longer be publishing :metadata as part of the clients >>> artifacts, >>> >> right? >>> >> >>> >> thanks, >>> >> Colin >>> >> >>> >> >>> >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote: >>> >> > Hi Apporv, >>> >> > >>> >> > Please remove the metadata module from any artifacts published for >>> >> > clients. It is only used by the server. >>> >> > >>> >> > best, >>> >> > Colin >>> >> > >>> >> > >>> >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote: >>> >> >> Hi Colin, >>> >> >> Thanks for the response. The only reason for asking the question of >>> >> >> publishing the metadata is because that's present in previous client >>> >> >> releases. For more context, the description of PR >>> >> >> <https://github.com/apache/kafka/pull/15127> holds the details and >>> >> waiting >>> >> >> for the confirmation there prior to the merge. >>> >> >> >>> >> >> Regards, >>> >> >> Apoorv Mittal >>> >> >> +44 7721681581 >>> >> >> >>> >> >> >>> >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe <cmcc...@apache.org> >>> >> wrote: >>> >> >> >>> >> >>> metadata is an internal gradle module. It is not used by clients. >>> So I >>> >> >>> don't see why you would want to publish it (unless I'm >>> misunderstanding >>> >> >>> something). >>> >> >>> >>> >> >>> best, >>> >> >>> Colin >>> >> >>> >>> >> >>> >>> >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote: >>> >> >>> > Thanks for reporting the blockers, folks. Good job finding. >>> >> >>> > >>> >> >>> > I have one ask - can anybody with Gradle expertise help review >>> this >>> >> small >>> >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1) >>> >> >>> > In particular, we are wondering whether we need to publish module >>> >> >>> metadata >>> >> >>> > as part of the gradle publishing process. >>> >> >>> > >>> >> >>> > >>> >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano >>> >> >>> > <pprovenz...@confluent.io.invalid> wrote: >>> >> >>> > >>> >> >>> >> We have potentially one more blocker >>> >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might >>> >> cause a >>> >> >>> data >>> >> >>> >> loss scenario with JBOD in KRaft. >>> >> >>> >> Initial analysis thought this is a problem and further review >>> looks >>> >> >>> like it >>> >> >>> >> isn't but we are continuing to dig into the issue to ensure that >>> it >>> >> >>> isn't. >>> >> >>> >> We would request feedback on the bug from anyone who is familiar >>> >> with >>> >> >>> this >>> >> >>> >> code. >>> >> >>> >> >>> >> >>> >> --Proven >>> >> >>> >> >>> >> >>> > >>> >> >>> > >>> >> >>> > -- >>> >> >>> > Best, >>> >> >>> > Stanislav >>> >> >>> >>> >> >>>
