Fix swift-java.config not being loaded from dependency module directories

[sidepelican]

Description

Currently, swift-java.config is not correctly loaded when placed in a dependency package, unless it is located directly under the /Sources/ directory.

The following line attempts to scan for the configuration file, but if the file is not found at the inferred path, it returns nil and falls back to the default configuration:

swift-java/Sources/SwiftJavaTool/SwiftJavaBaseAsyncParsableCommand.swift

Line 172 in 8cf1829

earlyConfig = try readConfiguration(sourceDir: moduleBaseDir.path)

Observed Behavior

When a dependency is placed in a outer package, the tool fails to locate the config file:

[debug][swift-java] Load config from module base directory: /MyProj/lib/src/main/swift/Sources/MyDepLib
Failed to read SwiftJava configuration at 'file:///MyProj/lib/src/main/swift/Sources/MyDepLib/swift-java.config', error: Error Domain=NSCocoaErrorDomain Code=260 "The file “swift-java.config” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/MyProj/lib/src/main/swift/Sources/MyDepLib/swift-java.config, NSURL=file:///MyProj/lib/src/main/swift/Sources/MyDepLib/swift-java.config, NSUnderlyingError=0x1058b8eb0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}
[debug][swift-java] Running 'swift-java jextract' in mode: ffm // Expected JNI mode

This leads to incorrect behavior where settings defined in the config file are ignored. While javaPackage works because it is passed via command-line arguments, other configurations remain at their default values.

Changes

I have modified the plugin to ensure that the configuration file path is correctly passed to the underlying jextract command.

[sidepelican]

Removing javaPackage handling to the command as it already accounts for empty values.

swift-java/Sources/JExtractSwiftLib/Swift2Java.swift

Lines 40 to 42 in 8cf1829

	if config.javaPackage == nil || config.javaPackage!.isEmpty {
	translator.log.warning("Configured java package is '', consider specifying concrete package for generated sources.")
	}

[ktoso]

I'd like to understand what exactly is the usage pattern you're trying to enable using this change?

[sidepelican]

We are maintaining a common Core package that is shared between Server and iOS codebase.
We are currently in the process of porting this Core package to Android.

Our project structure is as follows:

.
├── proj-common
│   ├── Sources
│   │   └── Core
│   └── Package.swift
├── experimental-android
│   ├── lib
│   │   ├── src
│   │   │   └── main
│   │   │       └── swift
│   │   │           ├── Sources
│   │   │           │   └── AndroidCore // This package depends on `Core`
│   │   │           └── Package.swift 

When we set up swift-java within the Core package and attempt to use it from AndroidCore, the swift-java.config is not loaded correctly.

[ktoso]

Okey I think I get it -- problem being your unusual package structure here... I think that's fine then, we should be able to handle other layouts like that in mixed language projects since you may be not actually using AndroidCore as anything anyone would depend on so it living in not-root may be fine.

[sidepelican]

Thank you for your review.
Our current package structure might seem unusual. We're still in the trial-and-error phase and don't consider this to be our ideal configuration yet.