After upgrading, deploy:deploy uploads jars to a pom only endpoint

[thoastbrot]

Hi,

I'm having issues after upgrading from spring-boot-parent 3.2.5 to either 3.2.6 or 3.3.0.

What I'm doing is running maven to first build (a multi-module project including a parent pom module) using mvn install, then in a separate step running mvn with the explicit goals listed (to only run deploy without prior goals).

Now what's wrong? After the upgrade, it's uploading a jar built from the parent pom module as pom in the deploy:deploy step. I have no clue why that happens, but will provide a minimal project to reproduce (will take some time) and some lines from my project/logs here below. In the meantime, could you please help me identify the change leading to that behavior?

Some excerpts from my setup:

$ mvn -e -X validate jar:jar source:jar install:install deploy:deploy -Dorg.slf4j.simpleLogger.log.org.apache.http=debug -Dorg.slf4j.simpleLogger.log.org.apache.http.wire=debug
[snip]
Uploading to artifactory: https://rtf.example.com/[snip]/parent-7.0.0-20240528.082035-3.pom
[snip]
[DEBUG] http-outgoing-0 >> PUT /artifactory/[snip]/parent/7.0.0-SNAPSHOT/parent-7.0.0-20240528.082035-3.pom HTTP/1.1
[DEBUG] http-outgoing-0 >> Cache-Control: no-cache, no-store
[DEBUG] http-outgoing-0 >> Pragma: no-cache
[DEBUG] http-outgoing-0 >> Expect: 100-continue
[DEBUG] http-outgoing-0 >> Content-Length: 3309
[snip]
[DEBUG] http-outgoing-0 << "[\r][\n]"
[DEBUG] http-outgoing-0 << HTTP/1.1 100 Continue
[DEBUG] http-outgoing-0 >> "PK[0x3][0x4][\n]"

welp, and that's the beginning of a jar file instead of the expected xml. Response from artifactory, which doesn't like that at all:

[DEBUG] http-outgoing-0 << "{[\n]"
[DEBUG] http-outgoing-0 << "  "errors" : [ {[\n]"
[DEBUG] http-outgoing-0 << "    "status" : 409,[\n]"
[DEBUG] http-outgoing-0 << "    "message" : "Failed to read POM for '[snip]/parent/7.0.0-SNAPSHOT/parent-7.0.0-20240528.082035-3.pom': only whitespace content allowed before start tag and not P (position: START_DOCUMENT seen P... @1:1) ."[\n]"
[DEBUG] http-outgoing-0 << "  } ][\n]"

I tried various maven-deploy-plugin versions (3.1.0 to 3.1.2), which didn't affect the outcome.

[wilkinsona]

Are you certain that downgrading the deploy plugin took effect? I think #40727 is the most likely cause.

[thoastbrot]

I included this in my root pom:

  <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-deploy-plugin</artifactId>
                    <version>${maven-deploy-plugin.version}</version>
                </plugin>
            </plugins>
        </pluginManagement>
  <build>

which leads to the defined version within a generated effective pom, so I believe this is the case. But I also suspect something around that. I just can't find proof.

[thoastbrot]

My logs call me a liar. It's not effective (basically rendering the effective pom the liar 🗡️ )

Using spring-boot-parent 3.2.6 unconditionally leads to maven-deploy-plugin 3.1.2 and my settings are not effective.

[wilkinsona]

If you're using spring-boot-starter-parent, you can override the version using the maven-deploy-plugin.version property:

<properties>
    <maven-deploy-plugin.version>3.1.1</maven-deploy-plugin.version>
</properties>

[thoastbrot]

Thank you, although this was already defined, it was defined at the wrong place. I placed the property and plugin management in my root pom, but it had to be in the same pom which inherited from the spring-boot-parent (I just missed that hierarchical split situation).

So now we definitely know it's from this change... shall we continue this here? Can someone verify my use case as relevant for spring-boot?

[wilkinsona]

So now we definitely know it's from this change... shall we continue this here?

No, I don't think so. This should be reported to the maintainers of the deploy plugin so that they can investigate the apparent regression. Downgrading the deploy plugin to 3.1.1 should hopefully serve as a workaround in the meantime.

Can someone verify my use case as relevant for spring-boot?

I can't see any reason why your use case isn't relevant. Spring Boot's not really involved with the deploy process. It just manages the version of the deploy plugin and, other than a jar that's deployed potentially being produced by repackage, that's it.