I have a problem getting Maven to release to a Nexus server. Seemingly, it refuses to use my provided username and password (but there might be other problems as well).
When I first type 'mvn release:perform', I get a'not authorized'-error. However, some files are created on the Nexus, namely a pom with checksums etc. When I try a second time (without changing anything), I get a different error: '400 bad request'
When I delete the files and try again, I get the first error once again.
I have run this with the -X flag to see if I can make any sense of what is happening, and I have discovered that the first time I run the command, maven omits my username and password provided in settings.xml:
[INFO] [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://nexus.example.com/content/repositories/releases
When I run it the second time, it includes my credentials:
[INFO] [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://nexus.example.com/content/repositories/releases/ as developers
Notice it says 'as developers'
Of course I don't know that the fact that it prints it differently actually means anything, but it seems that way.
When I allow redeploy for the releases repository in Nexus, I always get the first variant (not authorized).
If anyone can tell me how I might force Maven to use my credentials (if that is indeed what it is not doing) or on what else might be wrong, I would be very happy.
I have got it working now, by specifying in the maven release plugin that it only deploy, and not deploy and deploy site as is default.
mvn site:deploy fails with the error: Wagon protocol 'http' does not support directory copying.
Of course, my original error message did not refer very much to site at all.
Way to produce useful error messages, Maven!
I found a way to force preemptive authentication here: http://maven.apache.org/guides/mini/guide-http-settings.html (it didn't solve my problem, but it is an answer to the title.)
Related
$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/org/jooq/jooq-codegen-maven/3.9.1/jooq-codegen-maven-3.9.1.pom
I am executing this command, but it takes forever and got stuck here. My network is all good and I tried the command at different time but ended with the same. What might be the problem?
I've seen all kinds of problems with this. No idea what your specific issue is but here's a few possibilities
Your traffic is going through some kind of stateful package inspection/firewall/antivirus/IDS/bluecoat/etc and it's interfering and/or silently dropping the connection
There's some issues validating the certificate
The server is offline, which happens from time to time but is unlikely
Your settings.xml file is redirectly elsewhere and that "elsewhere" location is misbehaving.
A few suggestions to work around the issue
try disabling https (i know) by using settings.xml to remap the apache repo from https to http.
try disabling any antivirus/firewall (temporarily) to try and isolate the problem.
check to make sure your hard drive is not full
To troubleshoot run mvn with --debug flat to see any issues to find if mvn is stuck on any command. Based on this, if you still need help, please update this question
mvn --debug ...
I'm a groovy n00b and trying to use http-builder, but ALL of the examples on the web just reference the same #Grab statement which doesn't work. I assume it is because codehaus.org isn't hosting groovy stuff anymore. I've tried downloading the source from github and building it with Maven, but the build fails.
How and where am I supposed to get httpbuilder for groovy?
Things I've already tried:
Deleting the grapes directory from this post didn't work.
I got this code snippet from this other post, but it doesn't work for me either.
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7' )
def http = new groovyx.net.http.HTTPBuilder('http://www.codehaus.org')
println http
Here is the error in the IntelliJ console:
/Users/kenny/Sites/inadaydevelopment.com/reports/fetch_windows_appstore_report.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during conversion: Error grabbing Grapes --
[download failed: xerces#xercesImpl;2.9.1!xercesImpl.jar,
download failed: xml-apis#xml-apis;1.3.04!xml-apis.jar]
EDIT 1:
Tried running it from the command line, still same error message.
Tried grab artifacts in IntelliJ, but that failed too:
I wondered if it was Mac related, and bingo. I uploaded this script to my CentOS server and it ran just fine. There is something related to MacOSX+groovy that is causing the problem.
Got it! It looks like it was the maven cache that was the problem.
I found the solution on this page:
rm -rf ~/.m2/repository ~/.groovy/grapes
I had previously tried removing the ~/.groovy/grapes cache, but that didn't fix the problem. Removing the ~/.m2/repository is what actually did it for me.
This works fine from the groovy console and from the command line.
The http-builder project is hosted on Maven Central.
Grab will actually use JCenter, but JCenter mirrors Maven Central so this resolution works.
Not sure why you would have trouble resolving transitive dependencies... it may be that you are using a proxy, for example... could also be your settings for Maven or Ivy... Check the Groovy Grapes documentation to see if you might inadvertently have something configured that causes this problem.
Also, try from groovyConsole or the command-line to rule out some conflicts within IntelliJ.
From IntelliJ, point to the Grab annotation and hit Alt+Enter. Then select grab artifacts and Enter.
It should work (works for me) and you should be able to run the script without problems.
If it complains about Ivy not being in the classpath, just add Ivy to the module dependencies and it will work.
I have a library that I want to use Travis-CI on.
It is written in Java and uses Gradle as a build system and deploy to Bintray.
When Travis-CI runs the tests, it fails because I do not store my username and password in plaintext in the git repo.
What went wrong:
A problem occurred evaluating root project 'project-name'.
Could not find property 'bintray_net_user' on com.jfrog.bintray.gradle.BintrayExtension_Decorated#18be0f81.
This is happening because I have not committed my gradle.properties.
How to I tell it not to run the deploy code, or otherwise fake it out?
I guess you're usually passing this property using -P commandLine option? The easiest fix for you might be to check if the property is available before you use it and initiate it with a sensible default if not:
if(!project.hasProperty('bintray_net_user')){
project.ext.bintray_net_user = 'default'
}
You can add user credentials stored to your .travis.yml secure environment variables.
Since you always have one of the two (local gradle.properties, or parsed .travis.yml), it will work correctly.
Naive use of the built-in settings sometimes results in hanging connections. It is likely some network issue outside of my control.
I would like to know how I can set a timeout and a retry for both downloading artifacts and publishing artifacts.
I have found a connection timeout and read timeout setting for HTTP wagon, but I have not found a retry option.
For publishing, I found a retry option, but no timeout setting.
http://maven.apache.org/guides/mini/guide-http-settings.html#Connection_Timeouts
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
Edit what I want is the equivalent of curl's --max-time, --retry and --retry-delay options for maven and gradle downloads and publishes.
I tried to dig into this topic as well, but did not find much. Except one thing. Since Gradle 4.3 (thanks to PR) you can put to gradle.properties something like:
systemProp.org.gradle.internal.http.connectionTimeout=120000
systemProp.org.gradle.internal.http.socketTimeout=120000
Maybe once https://github.com/gradle/gradle/issues/4629 would be resolved, life will be much easier.
Gradle has built-in Maven compatability and it will create the .m2 or .gradle archive directories for you. To retry, all you need to do is just re-run your build over and over until all artifacts are complete.
I am at a clients site, behind a firewall. Im trying to compile but gradle keeps trying to check my dependencies. The corporate firewall explicitly blocks maven downloads so my build is failing. Now I have compiled before, so the dependencies do already exist in my [user]/.gradle folder, but its been more than 24 hours so gradle is trying to do its daily "lets check the repo and make sure nothing changed stuff."
Is there a command switch or anything that im just simply not seeing here to tell gradle to bypass this version check and simply compile the code? I would even be happy with a command switch that says I don't care if dependency resolution failed, compile anyways.
Try the --offline command line switch.
You still have to get it to compile once to grab the dependencies online, so --offline only works once you have compiled successfully one time.
The only way I was able to get this to work was to tether my phone to my machine and connect to my cellular service for internet instead. That way, I bypassed my company's proxy and firewall and was able to download the dependencies once.
After that, I was able to then compile when connected to the corporate network instead. Just don't clean your project or else you'll be back where you are right now.
I found this question because I wanted to short-circuit the Maven dependency checks in a git pre-commit hook that runs gradle check for better performance. I ended up doing:
if ! ( gradle --offline check || gradle check ); then
exit 1
fi
which tries once with --offline, and then tries again without --offline if the first try fails.