I need to fetch with an HTTP GET the latest version of the following Maven artifact as a JSON document:
https://mvnrepository.com/artifact/org.keycloak/keycloak-core
I'm trying with search.maven.org:
https://search.maven.org/?g=org.keycloak&a=keycloak-core&sort=latest&core=gav&rows=1
However I'm not getting anything as response
Previously I have been using "https://search.maven.org/solrsearch/" but recently I see this is going in timeout quite often
Any help?
Thanks
Related
As shown below, when send the request body, the request header is send as the body content.
[enter image description here][1]
I compared the 3.x and 4.x codes, find two versions on the processing of RetryAndFollowUpInterceptor.intercept() is different.
The 4.x version calls the detachWithViolence methods in the finally to release the resource, but the 3.x version does not release the resource if an exception occurs, this results in unsuccessfully send data in the Buffer being consumed by the next request.
Please help to fix this BUG in version 3.x, thank you!
List 135 of class okhttp3.internal.http.RetryAndFollowUpInterceptor does not execute when an excption is thrown.
Because the difference between the two version is too big, the team will not upgrade for the time being.
Could you fix the BUG on the 3.x version?
We are getting the following error in our project, when will this URL be back?
> Task :dependencyCheckAnalyze
Verifying dependencies for project cckm-app
Checking for updates and analyzing dependencies for vulnerabilities
Error retrieving https://nvd.nist.gov/feeds/json/cve/1.0/nvdcve-1.0-modified.meta; received response code 404.
Unable to continue dependency-check analysis.
Unable to update Cached Web DataSource, using local data instead. Results may not include recent vulnerabilities.
> Task :dependencyCheckAnalyze FAILED
FAILURE: Build failed with an exception.
#Ashwani, we are seeing the same. The NIST NVD feeds (both 1.0 and 1.1) were having issues last week. The 1.1 feed (https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.meta) looks as if it is working correctly again today. However, the 1.0 feed still looks like it is offline or broken. We've been unable thus far to try and make anyone at NIST aware of any potential issue with the feed.
nist have renamed this file to 1.1 in their next update:
check this changelog
New file's link is:
https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.meta
and This file was being used by Owasp-dependecy-check-gradle in our case, so we updated that to 6.0.1 version:
https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/index.html
Using gradle wrapper and specifying an internal repository URL to download the zip distribution - I followed the instructions from here: https://docs.gradle.org/5.2.1/userguide/gradle_wrapper.html#sec:authenticated_download
The https\://<username>:<password>#... in the distributionUrl works fine, but it's sub-optimal - we don't want credentials checked in source control. I tried:
systemProp.gradle.wrapperUser=<username>
systemProp.gradle.wrapperPassword=<password>
and confirmed that the properties are being set; however, they seem to be completely ignored. I keep getting a 401 unauthorized error when trying to access our internal repository. I tried all possibile combinations: systemProp.gradle.wrapperUser=username, gradle.wrapperUser=username and wrapperUser=username, nothing seems to work.
Any help is much appreciated.
Well, it turns out the issue was not with Gradle, but with IntelliJ, which seems to be overriding or completely ignoring the properties above. From a Unix shell script, everything works as advertised.
(This question elaborates on a a question I asked earlier, but with enough differences that I think it warrants a separate question)
This post on the Gradle forums describes similar symptoms, but not quite the same as my problem.
Like the poster there, I get the error:
Plugin with id 'org.sonarqube' not found.
when trying to use the SonarQube Gradle plugin with the following in my build.gradle file:
buildscript {
repositories {
mavenLocal()
maven { url 'http://[artifactory-url]:8081/artifactory/plugins-release/' }
}
dependencies {
classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2")
}
}
apply plugin: 'org.sonarqube'
He says that his instance of Artifactory has cached the plugin, whereas mine hasn't. Similar to him, I'm behind a corporate firewall, and have no admin rights on Artifactory, but I can see that the plugins-release virtual repo does include both https://plugins.gradle.org/m2 and http://jcenter.bintray.com. Ordinarily, simply requesting a library from our Artifactory server makes it find and cache that library immediately, but in this case it is clearly failing.
When I remove the apply plugin... line, I see the following error:
> Could not find org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2.
Searched in the following locations:
file:/C:/Users/[username]/.m2/repository/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
file:/C:/Users/[username]/.m2/repository/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.jar
http://[artifactory-url]/artifactory/plugins-release/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
http://[artifactory-url]/artifactory/plugins-release/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.jar
So, I'm fairly sure that Artifactory is failing to find and cache the plugin. If I browse to https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom, I can get to the POM file, and the same for the JAR file, but I notice that if I browse to https://plugins.gradle.org/m2/org/sonarsource/scanner, it doesn't include 'gradle' as a subdirectory. I don't know if that's relevant, but perhaps that's the cause of the problem I'm seeing with Artifactory?
I'm not sure whether to raise this as a bug against the plugin, or if it's an Artifactory issue, or simply some kind of misconfiguration on our side. Any thoughts much appreciated!
Update with trace
Thanks to #drorb I got a trace from Artifactory, and found:
2016-04-12T10:28:40.918+01:00 Executing HEAD request to https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/1.2/sonarqube-gradle-plugin-1.2.pom
2016-04-12T10:28:40.924+01:00 Received status {} (message: 501) on remote info request - returning unfound resource
501 is 'not implemented', so I assume this is telling me that the plugins.gradle.org repo doesn't support HEAD requests, which seems to mean Artifactory can't query it properly. I'm surprised that it works for others though - perhaps there's some Artifactory config I can get changed to not do the HEAD request?
Further update with cause, but not really an answer
Further digging made me realise that the HEAD request does in fact give me a proper response (303 which leads to a 200), so I think the issue is connectivity from our Artifactory server. This doesn't seem worth adding as an answer, but I'll leave it here in case it helps someone else experiencing similar issues.
Here is a snippet of our Gradle conf, which works:
buildscript {
repositories {
maven {
url "http://[artifactory-url]:7980/artifactory/libs-release"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2"
}
}
apply plugin: 'org.sonarqube'
The only difference I can see is that we put /artifactory/libs-release in the maven url, while you have /artifactory/plugins-release. Perhaps you should try pointing to libs-release, and see if that works?
I am new to parse and I am trying to figure out how to handle the version number.
I have been deploying some cloud code a bunch of times. So when I last deployed it gave me this message:
Uploading source files
Finished uploading files
New release is named v18 (using Parse JavaScript SDK v1.2.19)
So I thought I could go and hit:
https://api.parse.com/18/functions/someFunctionIWrote
So there I tried to use version 18 because of what I saw after deploying. That does not work and it returns a 404.
So, then I tried to hit:
https://api.parse.com/1/functions/someFunctionIWrote
this works and return the JSON I wanted.
So, what am I missing here?
I thought that every time I deploy the version would match. Do I need to specifically go in and change the current version somehow?
Can somebody help understand how to think about this correctly?
Thank you
If you ran a "parse deploy" it put v18 up there for you the URL stays the same.
The version in cloud can be verified in the terminal by typing: "parse releases"