[BUG] Fails to download jars #680
Comments
|
Seeing the same. Blocking deployments for my team. |
|
Even we are blocked |
|
Blocked as well when installing through NPM per instructions from https://openapi-generator.tech/docs/installation/ |
|
Is there an alternative plan? |
|
I confirmed that it works fine when using 'openapitools/openapi-generator-cli' docker images. |
|
Hi, we're having the same issue. Also blocks deployments. Seems like the repo is offline. |
|
Same here too. |
|
We use as there are bugs in openapi-generator 6 that affect us, but now we cannot download 5.4 due to this outage and As a workaround, use a static copy of the 5.4.0 openapi-generator jar and access that directly via One can download the needed jar from maven, such as |
|
Creating an It appears that sometimes the file is not generated for some reason. When it is being generated everything works fine. I can't find any obvious reason (permissions, etc) for the file not to be generated. This started happening in the last couple of days. |
|
I looked into this a bit, and it seems related to the not-so-great uptime of search.maven.org: This will cause failures when:
In other words, you're in trouble in all cases if It seems like validation via the |
|
For contrast, here's the uptime of the CDN from where the openapi-generator jars are actually downloaded: It would be great if there was a way to specify the exact openapi-generator version to use, and skip the query step so your usage of the tool is decoupled from |
|
the situation is aggravated because the command does not return a non-zero code, so it does not stop in CI and it silently fails in some cases. |
The --custom-generator param doesn't seem to work for me. It still tries to use the version set via |
|
we are encountering same issue "Request failed with status code 502" in our corporate network. I think that it is a common scenario to haven nexus configured as mirror for maven. So i would suggest: |
|
alanwguo yes, that is how I'm using it. I'm using this openapiGeneratorVersion=5.4.0
cat <<EOF >| openapitools.json
{
"\$schema": "./node_modules/@openapitools/openapi-generator-cli/config.schema.json",
"spaces": 2,
"generator-cli": {
"version": "${openapiGeneratorVersion}"
}
}
EOF
That is, I think the `openapi-generator-cli` will use the version in the `openapitools.json` file,
but calling `openapi-generator-cli version-manager set 5.4 stable` will still force it to
lookup versions in Maven repo to verify it, so to fix this issue, you need to not use that command. |
|
Seeing the same issue magma/magma#14860, but for us it seems to be flaky, see workflow runs. It started ca. 1 week ago. |
|
I have the same problem when validating an openapi schema in an Azure pipeline. On the other hand, it is possible to specify a The Here is my {
"scripts": {
"validate:openapi": "openapi-generator-cli validate -i ../path/to/openapi.yaml",
},
}
And the part of the CI shell script in the pipeline that validates the openapi schema # If search.maven.org is down the openapi-generator-cli-x.y.z.jar
# won't be downloaded and the command will fail
# The issue is described at https://github.com/OpenAPITools/openapi-generator-cli/issues/680
set +e;
# The next command will automatically check and download the latest version of openapi-generator-cli
# Let's capture the command exit status.
# If exit status is not zero then fallback on a static version of the jar (may not be the latest version)
npm run validate:openapi
exit_status=$?
# Exit immediately if a command returns a non-zero status
set -e;
if (( exit_status != 0 )); then
echo ""
echo "Failed to fetch version of openapi-generator-cli (exit status=$exit_status)"
# Use the last modified openapi-generator jar stored in static dir as fallback
fallback_jar_version=$(basename -s .jar $(ls -t ./static/openapi-generator-cli/*.jar | head -n1))
echo "Using fallback library openapi-generator-cli-$fallback_jar_version.jar"
# Create or replace openapitools.json file and force the use of the fallback version
cat <<EOF >| openapitools.json
{
"\$schema": "./node_modules/@openapitools/openapi-generator-cli/config.schema.json",
"spaces": 2,
"generator-cli": {
"storageDir": "./static/openapi-generator-cli",
"version": "${fallback_jar_version}"
}
}
EOF
# Retry
npm run validate:openapi
fi
# Remove openapitools.json
rm -f openapitools.json |
|
It is back.
|
|
When going to https://search.maven.org, I get this:
It is probably related... |
|
We're seeing this issue very often in the last few days, a rerun of the build mostly works. Would it make sense to implement a basic retry of the maven search call in the openapi-generator-cli? |
|
happening again today. this project needs to stop depending on search.maven.org, which is described as "legacy" by its maintainers and has shown a history of being unreliable. the offending function is here. I'm unfamiliar with the java ecosystem - would if be bad practice to bypass the search and make a request directly to |
|
@rettgerst what helped us was running |
|
Anyone struggling with this, I chose to submit the jar package to At the same time, I also have |
Please differentiate the bug
🐛 Bug Report:
Describe the bug
When we run the generator for the first time expecting to get resolved from the PATH (
openapi-generator-cli version) it hangs and after a while gives the following error:Steps to Reproduce
Install like this
Now try running:
Strangely enough, changing the directory seems to work
You can break it again:
The above will give you the same error
Expected behavior
Screenshots
If applicable, add screenshots to help explain your problem.
Operation System (please complete the following information):
Package System (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: