dlmiles / gradle-xjc-plugin

A Gradle plugin to run the XJC binding compiler during a build
MIT License
3 stars 0 forks source link

404 from https://maven.pkg.github.com/dlmiles/gradle-xjc-plugin #35

Open Strongbeard opened 4 months ago

Strongbeard commented 4 months ago

When I add the config from the README.adoc to my settings.gradle and build.gradle it tells me that it cannot find the plugin. I have additionally tried combinations of:

I noticed that when I try to curl https://maven.pkg.github.com/dlmiles/gradle-xjc-plugin directly I get a 404 status code back with a body of "404 page not found". I tested that the github token I generated works with curl -v -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/user/issues.

If github does not supply a consistent way to distribute the plugin, is it possible to publish it to the Gradle Plugin Repository?

dlmiles commented 3 months ago

Thanks for your report, sorry for the slow reply I have just noticed your issue while running through various repos checking up on them.

It is my intention at the next major update to publish this in the Gradle Plugin Repository, maybe also Maven Central. One of the issues I need to clear up is exactly what GAV axis it will be published as externally and understand better maybe the Gradle plugin descriptor package and the gradle plugin implementation package split. At this time the worst case scenario looks like a timescale over the next 4 months. Now I know there is some 3rd party interest in doing this, I can attempt to speed up the timeline.

The infrastructure has slowly been put in place within this project towards the above goal, I was however providing sufficient time for the upstream author to collaborate on the upstream patch submissions to potentially respond favourably to get things merged upstream.


The distribution location that is reliable should be: https://github.com/dlmiles?tab=packages&repo_name=gradle-xjc-plugin But maybe my instruction are incorrect, missing details, or assume a view of the repo that has push access.

It is a pain as GH does not provide a browsable UI to help diagnostics.

However if we look at the packages published with this project from the link just above, then select one of the packages, then on the right hand side is a list of published files.

The information on this screen can be turned into a Maven2 style path such as below:

wget --header "Authorization: bearer $GITHUB_TOKEN" "https://maven.pkg.github.com/dlmiles/gradle-xjc-plugin/org/darrylmiles/forked/org/unbroken-dome/gradle-xjc-plugin/2.2.0/gradle-xjc-plugin-2.2.0.pom"

wget --header "Authorization: bearer $GITHUB_TOKEN" "https://maven.pkg.github.com/dlmiles/gradle-xjc-plugin/org/unbroken-dome/xjc/org.unbroken-dome.xjc.gradle.plugin/2.2.0/org.unbroken-dome.xjc.gradle.plugin-2.2.0.pom"

Note the different groupId names in use here, something I need to consider/fix/resolve before I publish to Gradle Portal.

This should then result in the download of the artifact. The GITHUB_TOKEN needs the scope read:packages enabled, maybe this can be done via the Settings -> Developer Settings -> Personal Access Token -> Tokens (classic) -> Generate new token (Generate new token (classic)) -> TICK [read:packages] -> Generate Token

I have validated this works with another GH account (that is not dlmiles).

This wget exercise is just to prove the packages are there at the usual GAV path when it is well formed, and you pass GH authentication requirements for access.


I have a project in my repo that consumes this project https://github.com/dlmiles/java-schema-ipxact maybe the configuration from this can be looked at to work out how to consume it. If my instructions are incorrect or missing some details or I have a custom $HOME/.gradle setting I did not document doing the heavy lifting.

TL;DR version:

 git clone https://github.com/dlmiles/java-schema-ipxact
 cd java-schema-ipxact
 export GITHUB_USERNAME="your_username"
 export GITHUB_TOKEN="your_token"  # must have read:packages scope
 ./gradlew --refresh-dependencies clean  # force all deps to be pulled in now
 unset GITHUB_USERNAME # not needed now
 unset GITHUB_TOKEN
 ./gradlew clean assemble check

I have not perform much external testing, taking a fresh 3rd party system (and a GH auth that is not my account) to validate all the instructions work correctly.

The closest thing that exists is another project in my GH repos list, that uses a workflow to build itself using the packages published by this project.

Here are some snippets that may help from a the gradle project that is externally hosted and built:

settings.gradle:

 pluginManagement {
    // We are using this version of gradle-xjc-plugin because 2.0.0 does not
    // support all the building modes we use.  Pull requests are upstream.
    repositories {
        // 3rd party releases and SNAPSHOTs
        maven {
            //url "https://dlmiles.github.io/gradle-xjc-plugin/java8/maven2"
        url = "https://maven.pkg.github.com/dlmiles/gradle-xjc-plugin"
            content {
                // this repository *only* contains artifacts for specific groups
                includeGroup "org.unbroken-dome.xjc"
                includeGroup "org.unbroken-dome"

                includeGroup "io.github.dlmiles.xjc"
                includeGroup "io.github.dlmiles"

                includeGroup "org.darrylmiles.forked.org.unbroken-dome.xjc"
                includeGroup "org.darrylmiles.forked.org.unbroken-dome"
            }
            credentials {
                // github requires any valid credentials even to GET packages
                username = System.getenv("GITHUB_USERNAME")
                password = System.getenv("GITHUB_TOKEN")
            }
        }

        // Official releases only
        gradlePluginPortal()
    }
}

ipxact-1685-2014/build.gradle

plugins {
    id 'java'
    id 'org.unbroken-dome.xjc' version '2.2.0'    // this maybe the misleading detail in README.adoc
    // the intention behind the last release is what has been documented, but what actually works today is this
}

I then have this github workflow action to manage the local locating of the gradle plugins (note the GITHUB_TOKEN will have permissions: package: write from workflow.yml config which implies package:read): https://github.com/dlmiles/java-schema-ipxact/blob/master/.github/workflows/build.yml#L80

     # Resolve external dependencies (this will validate org.darrylmiles.forked.org.unbroken-dome.xjc is accessible)
      - name: Gradle - refresh-dependencies
        env:
          GITHUB_USERNAME: ${{ github.actor }}
          GITHUB_TOKEN:    ${{ secrets.GITHUB_TOKEN }}
        run: ./gradlew --refresh-dependencies clean

The other locations such as the maven2 part of gh-pages while it is there and exists, is unreliable for use directly from maven/gradle. It may only have the latest version up there at one time, it may disappear if GH disable project after 3 months of no activity, etc....

I started using the GH Maven package publish function when I started to make versioned releases as a method towards ironing out the details for publishing to Gradle Plugin Portal and/or Maven Central.

HTH

dlmiles commented 3 months ago

Feedback to self to address at next maintenance.

There is no public published version of 2.3.0-SNAPSHOT or anything *-SNAPSHOT so ideally the front page documentation should display the latest GA release version at all times, maybe a dev branch that is not the default branch is used to contain the patches adding *-SNAPSHOT, until they are merged to the default branch during release.

Resolve the Gradle Plugin descriptor groupId to be that which is currently published org.darrylmiles.forked.org.unbroken-dome.xjc but currently it only works on the original org.unbroken-dome.xjc because that is not something I had fully understood at the time of making the change.

I should then republish additional packages copies for back-versioned releases under the new Gradle Plugin descriptor GAV so there is a complete set under a single GAV, before looking at publishing it wider (GPP/MavenCentral). This is so that it should be possible for users to use the upstream 2.0.0 release and switch to this 2.0.0 and see no net change. Before then upgrading and migrating to newer releases.