GH-41173: [Java] Add spotless configuration for Maven pom.xml files

[laurentgo]

What changes are included in this PR?

To make sure that all pom.xml files follow the same convention regarding indentation and organization, add spotless plugin with sortPom module to check and format the files automatically.

Update Java developer documentation to provide the link to the convention and instructions on how to use spotless

Finally apply the convention to all pom.xml files

Are these changes tested?

No new test as no code change (just formatting)

Are there any user-facing changes?

None

• GitHub Issue: [Java] Format pom.xml files using Apache Maven pom.xml 2008 convention #41173

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[github-actions]

⚠️ GitHub issue #41173has been automatically assigned in GitHub to PR creator.

[vibhatha]

@laurentgo there is already and effort to add this module by module: #40757

[laurentgo]

I saw the spotless change but I assumed (wrongly) it was for Java files, not pom.xml. My bad.

I would argue that pom.xml have a style on their own, and that there's only a few of them (compared to the numerous java files).

At the same time, as someone who's offering/trying to clean up those files, it's kind of hard to have to match each file own style...

[lidavidm]

I think we can do this first. @vibhatha would it conflict?

[vibhatha]

This is formatting all poms. I thought we wanted a smaller diff as a previous PR was closed for the length of it.

If this solves the problem, let's close the issues created per module.

Also I would recommend to check existing issues before creating new ones.

[vibhatha]

I saw the spotless change but I assumed (wrongly) it was for Java files, not pom.xml. My bad.

I would argue that pom.xml have a style on their own, and that there's only a few of them (compared to the numerous java files).

At the same time, as someone who's offering/trying to clean up those files, it's kind of hard to have to match each file own style...

It's fine. Let's try to wrap up this PR.
But let's close the other tickets if it closes the expected via this PR.

Objective is to format code and xml both.

If this PR is only doing xml format we can declare that and make code changes in the other list.

Also please feel free to work on those issues if it's in the scope.

[lidavidm]

The previous PR formatted nearly everything.

[vibhatha]

Looks fine to me. Let's verify the CIs.

[vibhatha]

The previous PR formatted nearly everything.

Yes, except the Java. I looked into the changes. I am not an expert with spotless, but this only formats the pom.

It would be very hard to be sure about all formatting. I will run the crossbows and validate. That should be one validator.

I think we decided to go module by module since it's hard to eye-check everything in a single PR.

[vibhatha]

But this PR is manageable. We can use the other spotless tickets to format code and licenses.

[vibhatha]

@github-actions crossbow submit -g java

[github-actions]

Revision: 590d4e9

Submitted crossbow builds: ursacomputing/crossbow @ actions-c929748329

Task	Status
java-jars
test-conda-python-3.10-spark-v3.5.0
test-conda-python-3.11-spark-master
test-conda-python-3.8-spark-v3.5.0
verify-rc-source-java-linux-almalinux-8-amd64
verify-rc-source-java-linux-conda-latest-amd64
verify-rc-source-java-linux-ubuntu-20.04-amd64
verify-rc-source-java-linux-ubuntu-22.04-amd64
verify-rc-source-java-macos-amd64

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 7003e90.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 8 possible false positives for unstable benchmarks that are known to sometimes produce them.