Publication failed after merge of new release YAML files

[edeweerd1A]

The split release scripts were merged on the quarkus-logging-splunk Quarkiverse extension.
A release was attempted with the new scripts and it does not seem to work:

The POM file
/home/runner/work/quarkiverse-release/quarkiverse-release/repository/io/quarkiverse/logging/splunk/quarkus-logging-splunk-parent/4.0.0/quarkus-logging-splunk-parent-4.0.0.pom
cannot be uploaded to Maven Central due to the following reasons:
 * The <repositories> block should not be present.

Here is the link to the failed publication: https://github.com/quarkiverse/quarkiverse-release/actions/runs/11497223021/job/32000478343

Is there something missing from the POM perspective for instance?

[gsmet]

I think it might be due to

quarkus-logging-splunk/pom.xml

Lines 57 to 71 in 5c9ec61

	<repositories>
	<repository>
	<id>central</id>
	<name>Central Repository</name>
	<url>https://repo.maven.apache.org/maven2</url>
	<snapshots>
	<enabled>false</enabled>
	</snapshots>
	</repository>
	<repository>
	<id>splunk</id>
	<name>Splunk Releases</name>
	<url>https://splunk.jfrog.io/splunk/ext-releases-local</url>
	</repository>
	</repositories>

. But not sure why we are enforcing that.

Do you still need the Splunk repository there?

Anyway, pinging @gastaldi as he will know more.

[gastaldi]

@aalmiray looks like this is another validation that can be relaxed in Jreleaser

[aalmiray]

Pomchecker has a --no-strict flag that can be used to skip this check. I think JReleaser should have an option to pass additional flags to pomchecker.

Could be done with both artifactOverrides (targeted) or at the deployer level (global).

[rquinio1A]

For info we need the 2nd repository as com.splunk.logging:splunk-library-javalogging is not published to Maven central (splunk/splunk-library-javalogging#17)

[gastaldi]

The central can be removed, but that shouldn't prevent publishing to Central AFAIK, I'll see what I can do

[aalmiray]

I'll get the fix done in JReleaser this weekend. You'll be able to use it via its early-access builds for the time being til 1.15.0 is released at the end of the month.

[gsmet]

My experience is that if you remove Central, the other repository will be contacted first - which might be slow and annoying.

[gastaldi]

I wonder if it's possible to shade this dependency in the extension's runtime, then the repository can be removed completely

[gsmet]

Well, you will need the repository to download the dependency anyway. Given Andres said he would provide a fix soon, we can probably just wait.

[rquinio1A]

My experience is that if you remove Central, the other repository will be contacted first - which might be slow and annoying.

Indeed you're right:

[INFO] Scanning for projects...
Downloading from splunk: https://splunk.jfrog.io/splunk/ext-releases-local/io/quarkus/quarkus-bom/3.15.0.CR1/quarkus-b
om-3.15.0.CR1.pom
Downloading from central: https://repo.maven.apache.org/maven2/io/quarkus/quarkus-bom/3.15.0.CR1/quarkus-bom-3.15.0.CR
1.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/quarkus/quarkus-bom/3.15.0.CR1/quarkus-bom-3.15.0.CR1
.pom (471 kB at 1.9 MB/s)

[gsmet]

Indeed you're right:

You'll get used to it :]

[gastaldi]

Well, you will need the repository to download the dependency anyway.

Yes, but that will be there only while building the binary, then the shade plugin will remove it from the pom.xml (assuming the repository element is moved to the runtime/pom.xml)

[gsmet]

Yeah, can't say I'm a big fan of shading. Now I have no idea if this extension is just a small thing with no security issues and a few classes or something that might be problematic in the end.

[aalmiray]

Well, you will need the repository to download the dependency anyway.

Yes, but that will be there only while building the binary, then the shade plugin will remove it from the pom.xml (assuming the repository element is moved to the runtime/pom.xml)

Rather use the flatten plugin to rewrite the pom to-be-published after shading.

[aalmiray]

Ready jreleaser/jreleaser@50d4915
Simply set pomchecker's strict property to false

deploy:
  maven:
    pomchecker:
      strict: false