Add repositories configuration option in swift-java.config

[bo2themax]

I was trying out a Gradle package and found out that the Maven Central repository was not enough for this package, so I added a configuration option for this. It can be configured in the swift-java.config file in the following format based on https://docs.gradle.org/current/userguide/supported_repository_types.html#sec:maven-repo.:

I’m not an experienced Java/Kotlin developer, but I believe this would meet the needs of most existing packages. If future issues arise, it could be extended to support Ivy and Flat directory repositories.

{
  "repositories": [
    { "type": "maven", "url": "https://repo.mycompany.com/maven2" },
    {
      "type": "maven",
      "url": "https://repo2.mycompany.com/maven2",
      "artifactUrls": [
        "https://repo.mycompany.com/jars",
        "https://repo.mycompany.com/jars2"
      ]
    },
    { "type": "maven", "url": "https://secure.repo.com/maven2" },
    { "type": "mavenLocal", "includeGroups": ["com.example.myproject"] },
    { "type": "maven", "url": "build/repo" }, // Relative to build folder of the temporary project, better to use absolute path here, no need to add `file:` prefix
    { "type": "mavenCentral" },
    { "type": "mavenLocal" },
    { "type": "google" }
  ]
}

Note: Authentication for private repositories is not currently handled. If you need to access packages from a private repository that requires credentials, you can use Maven to download the required artifacts and then reference them via your local Maven repository in your configuration.

Alongside this PR, I’ve also added:

• A JavaJson target to JavaDependencySampleApp.
• A dedicated test under the SwiftJavaTests target.
• Drafted documentation in SwiftJavaCommandLineTool.md. If you spot any incorrect wording, please let me know in the comments or add a review in the code.

---

Test results:

Sample App outputs:

[ktoso]

Looks OK but this isn't tested at all, Samples/JavaDependencySampleApp/Sources/JavaCommonsCSV/swift-java-with-custom-repositories.config Perhaps make a new target next to JavaCommonsCSV that uses this as its swift-java.config.

I'd be worried about having this accepted without the sample validating it.

[ktoso]

Would be good to document this in some docs as well, as otherwise it'll be hard to discover (we have md files in SwiftJavaDocumentation for docs, feel free to add one about resolving!)

[bo2themax]

Looks OK but this isn't tested at all, Samples/JavaDependencySampleApp/Sources/JavaCommonsCSV/swift-java-with-custom-repositories.config Perhaps make a new target next to JavaCommonsCSV that uses this as its swift-java.config.

I'd be worried about having this accepted without the sample validating it.

Yeah make sense, I'll add the target and some related documentation later

[ktoso]

Looks good overall, I'm a bit unsure about the added test; can we make it work with just resolve and without calling out to mvn?

[bo2themax]

Looks good overall, I'm a bit unsure about the added test; can we make it work with just resolve and without calling out to mvn?

I think so. I can only think of embedding the package inside the test resource, or maybe leveraging Gradle caches somehow.

[bo2themax]

@ktoso Beside the reviews, I also added a few more changes this time. It’s better to go through the whole diff again🙏🏻

• Removed System dependency from OrgAndrejsJsonTests, so it can be tested on Linux.
• Added a SimpleJavaProject to JavaRepositoryTests.
• Wrapped the nonResolvableDependency test in a compiler check for API availability for different versions of Swift.

These four jobs are now passed both on Linux(Ubuntu 25, Swift 6.1 & 6.2) and macOS(26, Swift 6.2), so they should be able to pass on ci runners as well.

Jobs for SwiftJavaExtract seem to fail on the main branch too, so it still fails with this pull request

[ktoso]

Some of the jobs sometimes crash during compilation and that's a known Swift 6.1 issue we're aiming to resolve soon, so don't worry if compilation crashes, we can ignore those failures.

[bo2themax]

Some of the jobs sometimes crash during compilation and that's a known Swift 6.1 issue we're aiming to resolve soon, so don't worry if compilation crashes, we can ignore those failures.

Got it, but I still need to update the licence header. I will request another review after.

[bo2themax]

@ktoso Two commits added

• Add missing license headers to Tests/SwiftJavaToolTests/SimpleJavaProject
• Update Swift Build steps when testing different Swift versions to avoid these two errors (Will increase CI times)
  • error: module compiled with Swift 6.1.2 cannot be imported by the Swift 6.2 compiler: /home/ubuntu/Downloads/swift-java/.build/aarch64-unknown-linux-gnu/debug/Modules-tool/SwiftJavaTool.swiftmodule
  • error: no such module 'SwiftJavaTool'

[bo2themax]

@ktoso Two commits added

• Add missing license headers to Tests/SwiftJavaToolTests/SimpleJavaProject

• Update Swift Build steps when testing different Swift versions to avoid these two errors (Will increase CI times)

  • error: module compiled with Swift 6.1.2 cannot be imported by the Swift 6.2 compiler: /home/ubuntu/Downloads/swift-java/.build/aarch64-unknown-linux-gnu/debug/Modules-tool/SwiftJavaTool.swiftmodule
  • error: no such module 'SwiftJavaTool'

@ktoso Strange behaviour on my Mac though, that’s why I committed the last change:

• swift build --build-tests --disable-sandbox failed with SwiftJavaTool not found error
• swift build --disable-sandbox && swift test succeeded

Each with a clean build, opened a issue in SPM

Screen.Recording.2025-08-31.at.16.22.51.mp4

[bo2themax]

To test the resolve command with SwiftJavaToolLib, I moved the core logic of ResolveCommand into a new utility type called JavaResolver within SwiftJavaToolLib.

Now both a clean swift build --build-tests --disable-sandbox and xcodebuild will pass, but you still cannot run tests in Xcode, due to the sandbox.