Maven - peer not authenticated - maven

A few days ago my maven stopped working. To be more specific it stops download dependencies. Below I note bunch of information and steps which I did in order to find solution.
I double checked settings.xml - this file is used also by my colleagues and they haven't any problems
I installed Maven 3.0.4, 3.0.5, 3.1.0 - it always fail during download dependencies
I have 3 computers - 2 with Ubuntu and 1 with Windows. On Windows it works great, on both Ubuntu it doesn't.
mvn clean install generates in debug mode something like that: Could not transfer artifact junit:junit:pom:3.8.1 from/to central...: peer not authenticated stacktrace
I tried to use additional parameters mvn -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true clean install
but it fails also. Output in debug mode ends with: Server key: Could not create EC public key: CKR_DOMAIN_PARAMS_INVALID
If I add all dependencies manually (copy&paste from my colleagues ~/.m2 directory) then mvn clean install works correctly. So, it seems to be a problem only with downloading.
Does anyone have any suggestions what can be wrong?

I found a solution for my problem. Be sure you have rights to write into {jdk_directory}/security/java.security file (in my case /etc/java-7-openjdk/security/java.security) and if so, then modify it this way:
from:
#security.provider.9=sun.security.ec.SunEC
security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
to
security.provider.9=sun.security.ec.SunEC
#security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
It fixed problem on all my computers (all with maven 3.0.4)

Related

mvn clean install stuck when doing tests - what am i missing?

I want to run my app as a windows service so i modified my pom to include
executable / true.
I tried "mvn clean install" - after a few moments, it starts doing tests but after more than 3 hours it shows only messages about websocket. I have websocket in my project, but what is the problem? Why the long running time ? Am i missing something ?
EDIT: I'm sorry about the picture, i thought the image would say more than i could say.
The only thing new about my project is the "executable - true " in the pom. I removed it and tried mvn clean install with another failure. I am thinking it has something to do with my mvn packages ? I am starting to remove them one by one to identify the source.
EDIT2: I found the source: removing websocket dependency completes mvn clean install in under 2 minutes. What is the message? Is it something wrong with my websocket ? It is the spring-boot-starter-websocket dependency.
I don't understand, why running the app in intellij works and mvn clean install doesn't ?
After simulating on a local project i believe that a local test is keeping the connection open and won't let spring finish.
Check the test and first uncomment it to isolate the problem.

How to update a bundle from Maven artifact with running Apache Felix

Currently I have a situation, where I develop a project, then run mvn install and it get's put into my local Maven repository as a simple JAR file
Then, I have a crafted by some other guys "environment" which includes a whole lot of bundles and stuff, and is ultimately run via mvn pax:run and it takes like 5 minutes to run
I would like to be able to just run felix:update <bundle-name> but I cannot fill the gap between a Maven JAR artifact in local Maven repo, and a ready-for-provisioning bundle that I could put somewhere to just run felix:update or whatever, maybe uninstall/install
When I try to run mvn pax:create-bundle with my project, it throws a Containing project does not have packaging type 'pom' exception
Any help is highly appreciated
UPDATE: I've noticed that problems with re-installed bundle begin in it's activator, with a ClassNotFoundException (although the class mentioned is and always present in the bundle, so it must an issue with classpath, ClassLoader setup or whatever)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation BundleWiringImpl.java:1574 at org.apache.felix.framework.BundleWiringImpl.access$400 BundleWiringImpl.java:79 at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass BundleWiringImpl.java:2018 at java.lang.ClassLoader.loadClass ClassLoader.java:357 at some.external.adapters.package.guice.SomeModule.configure SomeModule.java:46 at com.google.inject.AbstractModule.configure AbstractModule.java:59
If you have a path to a file which is the newly built bundle, you can update it from the Gogo shell as follows:
felix:update <bundleid> file:/path/to/file
refresh
Where <bundleid> is the numeric ID of the bundle that you want to update. The refresh command is needed in case any bundles depend on or import packages from the bundle you are updating; this command will cause the Framework to attempt to re-resolve them using the new dependency.
I am happy to accept #neil-bartlett's answer, though I have to add some more context:
1) one of the biggest issues I had initially is that a JAR-file in local Maven repo IS NOT THE SAME as an OSGi bundle. In order to create bundle, I had to run mvn bundle:bundle AFTER mvn install. And the bundle got created in target/ folder.
2) afterwards, in a GoGo shell, I could indeed run felix:update <bundle-id> file:C:/Users/blablabla/bundle-SNAPSHOT-2.0.jar, and for some reasons, these days it just works. The exceptions, mentioned in updates to original post, are indeed occurring, but they do not prevent proper installation of an updated bundle.

Jenkins + Maven Manual Installation

I installed Jenkins on to 2 new machines no-problemo!
But, when attempting to integrate Maven, I am having "command not found" in my Jenkins log, yet I can run mvn no problem in the command line.
So, I thought it was a PATH issue - so I added the /bin and also the / (of the location where Maven is extracted to), yet I'm still getting the error.
I tried adding the PATH to my ~/.bash_profile as well, so my current PATH is:
$PATH:/usr/local/bin:/Users/jenkins/apache-maven-3.5.2/bin:/Users/jenkins/apache-maven-3.5.2
Still, Jenkins will not find Maven. I do NOT want to globally install Maven, as it may affect the other 5 build servers we have that are working with Maven correctly (not sure how it's working).
The issue was resolved by simply re-connecting the Jenkins Slave. Thanks for your feedback!

Groovy install HTTPBuilder now that Codehaus shutdown?

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.

Build Error while building aperturejs

I am trying to build aperturejs with Readme.md instructions.
I cloned the repository and tried the command mvn clean install in the root directory of ApertureJs.
I got the following Build Error as in the screenshot,
I am using the latest version of Maven - 3.3.9
Thanks in advance.
By reading the error in your console, I could feel that you are not authorized to access the particular repository, which is shown in your console.
Copy the repository url and try it from a browser - hope you will not be able to access the repository, since you are not authorized.
Raise appropriate access and after getting access, then try mvn clean install.
Below is the Quick fix till the time you get the access:
Copy and Paste the respective jar/pom/folder from your colleague machine, in your .m2/repository/...
Run the mvn clean install with -o option so that it will look into your local repository for building your application
Thank you. The issue is solved. I posted this issue to Uncharted Software's Salt Repository and exactly like Clement Said, I was trying to access a repository that no more has access publicly. Therefore they gave a workaround.
It is available here -> https://github.com/unchartedsoftware/aperturejs/issues/22
Thanks a lot.

Resources