Publish repository artifacts

[barbeau]

Is your feature request related to a problem? Please describe.
We need a place to publish the artifacts from this library:

• Android - AAR file
• iOS - Swift SPM bundle
• JVM - JAR and metadata

JCenter Bintray is deprecated, so we need other options.

Describe the solution you'd like
GitHub Packages may be a solution. This would be nice for integration with CI as it would be relatively straightforward to publish from GitHub Actions.

Looks like there are GitHub guides for:

• Gradle (JVM) - https://docs.github.com/en/packages/guides/configuring-gradle-for-use-with-github-packages
  • These sites may be better for multiplatform - https://github.com/reduxkotlin/redux-kotlin, https://patrickjackson.dev/publishing-multiplatform-kotlin-libraries/, https://www.adsbynimbus.com/tech-blog/kotlin-multiplatform-and-github-actions

Android would be similar to Gradle with some changes for AARs vs JARs. This example from the android-maps-utils project may be useful:

• https://github.com/googlemaps/android-maps-utils/blob/main/.github/workflows/release.yml

I need to look more for Swift SPM examples.

Describe alternatives you've considered
Normal GitHub repo was mentioned as a possibility and showcased in a few demos online, but @ualch9 noted in #12 (comment):

binary distibution in the git repo is discouraged because spm downloads the repo's history as well.

https://pspdfkit.com/blog/2020/binary-frameworks-as-swift-packages/#targets

While it’s possible to check the binaries into the git repository, we decided to host the binaries on our own servers because Apple doesn’t recommend checking the binaries into the repository. This is to prevent git checkout slowdowns.

Additional context
There was some discussion of Swift SPM dependencies in #7 (comment) and #7 (comment).

cc @aaronbrethorst

[barbeau]

GitHub announced support for Swift as part of the Package Registry in June 2019:
https://github.blog/2019-06-03-github-package-registry-will-support-swift-packages/

...but from these links it looks like implementation is still in-progress:

• https://github.community/t/swift-package-registry/127398
• https://forums.swift.org/t/swift-package-registry-service/37219/75

@aaronbrethorst @ualch9 Do you know anything about https://swiftpackageregistry.com/? It's mentioned towards the end of the link in the 2nd bullet above.

[barbeau]

Oh, actually looks like https://swiftpackageregistry.com/ doesn't host artifacts, it's just a registry for packages hosted elsewhere, so that doesn't help.

FWIW, clicking through the top packages registered there, all of them I looked at hosted the Swift package files in the same GitHub repo as the project.

[barbeau]

If we do host within the same repo here, one potential way to avoid a huge issue with binaries in version control is to only publish updates to the Swift package when tagging a new release (not every commit to main branch). This would keep the number of huge files in the history to a minimum.

@ualch9 would the above work with Swift packages, to your knowledge? You mentioned something about needing to update on every commit previously.

[ualch9]

I was thinking, we can just upload a zip file to the GitHub Releases tab.
The URL format appears to be a permanent path, so we would only need to update the URL inside of package.swift whenever we push a new release.
Example URL: https://github.com/ualch9/opentripplanner-library-swift/releases/download/0.5/opentripplanner-library-swift-main.zip

[barbeau]

The URL format appears to be a permanent path, so we would only need to update the URL inside of package.swift whenever we push a new release.

@ualch9 I'm not sure I understand where the zip file comes in. Do you mean that looking at https://github.com/ualch9/opentripplanner-library-swift/blob/main/Package.swift, we would replace the path that current points to a folder with a pointer to a zip file?

So from:

// swift-tools-version:5.3
import PackageDescription

let package = Package(
    name: "OpenTripPlannerClientLibrary",
    platforms: [
        .iOS(.v13)
    ],
    products: [
        .library(
            name: "OpenTripPlannerClientLibrary",
            targets: ["OpenTripPlannerClientLibrary"]
        ),
    ],
    targets: [
        .binaryTarget(
            name: "OpenTripPlannerClientLibrary",
            path: "./OpenTripPlannerClientLibrary.xcframework" // <- This changes to a zip file?
        ),
    ]
)

...to:

// swift-tools-version:5.3
import PackageDescription

let package = Package(
    name: "OpenTripPlannerClientLibrary",
    platforms: [
        .iOS(.v13)
    ],
    products: [
        .library(
            name: "OpenTripPlannerClientLibrary",
            targets: ["OpenTripPlannerClientLibrary"]
        ),
    ],
    targets: [
        .binaryTarget(
            name: "OpenTripPlannerClientLibrary",
            path: "https://github.com/ualch9/opentripplanner-library-swift/releases/download/0.5/opentripplanner-library-swift-main.zip"
        ),
    ]
)

[barbeau]

After reading https://developer.apple.com/documentation/xcode/creating_a_standalone_swift_package_with_xcode, I think it would use url instead of path?

...
    targets: [
        .binaryTarget(
            name: "OpenTripPlannerClientLibrary",
            url: "https://github.com/ualch9/opentripplanner-library-swift/releases/download/0.5/opentripplanner-library-swift-main.zip"
        ),
    ]
...

[ualch9]

Yes, although I believe you will also need a checksum property, which can be generated using swift package compute-checksum path/to/library.zip.

https://github.com/PSPDFKit/PSPDFKit-SP/blob/master/Package.swift

.binaryTarget(
    name: "PSPDFKit",
    url: "https://customers.pspdfkit.com/pspdfkit/xcframework/10.3.0.zip",
    checksum: "885b1564f5419f2a49fc532ed038049596def549c094d361ba772851f0327034")

I will try out the url/checksum property on my machine sometime in the next day and let you know.

[ualch9]

@barbeau Sorry I got to this late,

1. Build the swift package using ./gradlew createSwiftPackage.
2. Zip up the resulting OpenTripPlannerClientLibrary.xcframework into OpenTripPlannerClientLibrary.xcframework.zip.
3. Run swift package compute-checksum path/to/OpenTripPlannerClientLibrary.xcframework.zip to generate the checksum.
4. Update package.swift to the new GitHub Release URL and the checksum generated in Step 3.

The package repo now only consists of a single Package.swift file. https://github.com/ualch9/opentripplanner-library-swift

---

Xcode defaults to using git version tags when determining which binary release to download. The screenshot shows that since ualch9/opentripplanner-library-swift.git does not have any tags, the version fields are all blank by default and I get an error if I press Next. The solution is to use branch instead.

[barbeau]

Nice! Thanks @ualch9 for testing this! This approach should work for iOS and is something I can automate via GitHub Actions (compiling, creating zip, creating release tag), so I'll plan to follow this approach on this repo.

[barbeau]

Recent article for publishing Android artifacts to Maven Central:
https://medium.com/nerd-for-tech/oh-no-another-publishing-android-artifacts-to-maven-central-guide-9d7f300ebd74