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.
Related
Until recently everything worked fine with our build process in Jenkins. We got a quite big project with many modules and a complicated dependency structure.
Suddenly, the build fails with error messages like the following:
Failed to execute goal certain-plugin:109:certainEar(certainEar)
on project app: certain plugin: Can't explode ear file
'app-SNAPSHOT.ear': Error, directory can't be deleted
The maven command that gets executed in the build pipeline and results in the error message is the following:
mvn -B -U package -DskipTests
A temporary workaround is manually deleting the affected directory. Previously I had a similar problem with the deletion of an ear, there it was possible to exclude the affected ear from this build step as it was not required there. Afterwards I got the error message mentioned above.
Now I found a (kind of) final solution: Adding clean to the targets of the maven command:
mvn -B -U clean package -DskipTests
Now the building step works fine. But why the heck does this happen? Do you have any hints what could lead to this behavior? I'm quite clueless to say the least.
Somehow this could have something to do with the extraction of an ear out of our big app ear. Shortly after we finished this and merged it into our master branch those errors began to arise. As I was not involved in this work it's hard to track down what happened there exactly and what could lead to this behavior. In parallel I will investigate what the colleagues did there. Hints from you what the reasons could be will certainly help to track this down.
I found nothing similar to this error messages online that helped me in any way.
Your solution "mvn clean" indicates me that your job is executing on a jenkins workspace that contains the execution of the previous job. I would recommend to always start your job by clearing what's in the workspace. In freestyle job, under section Source Code Management you can add the behavior
Wipe out repository & force clone
in pipelines, you would use checkout step
checkout([$class: 'GitSCM',
extensions: scm.extensions + [[$class: 'WipeWorkspace']] + [[$class: 'PruneStaleBranch']],
userRemoteConfigs: [[
url: '<git_url>'
]]
])
there are other ways to clean a workspace in a pipeline like cleanWS and deleteDir. Do prefer the checkout WipeWorkspace plugin
I've set up a build on Jenkins for a Maven project, and I would like to build it without running any of the tests. I've tried entering "clean install -DskipTests" in the goals field, like this:
But it doesn't work. What am I doing incorrectly?
Note: I want to skip the tests without touching the pom. I have a separate build that DOES run the tests.
The problem is that I omitted =true. I was able to build without running tests by entering:
clean install -DskipTests=true
Just to extend the answer, maven has 2 options for skipping tests:
-DskipTests=true — The one that was mentioned. With this parameter, maven ignores tests completely.
-Dmaven.test.skip=true — With this option maven compiles the tests but doesn't launch them.
So you may want to use the second option instead as fast code compile validation. E.G.: if you develop some library or module that will be used by some one else you must be sure that you don't brake contract with the client. Tests compilation can help you with this.
Use either of these parameters depending on your needs.
use "Goals and options" value is "clean install -DskipTests=true".
it works like a Charm. I saved hours of time using this Option. :-)
I use option "-DskipTests=true" in "Invoke top-level Maven target" -> "JVM Options" and it works fine.
I have created a maven vaadin project using the command line like this:
mvn archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-application -DarchetypeVersion=7.1.9
Then I change into the folder of the application and I give at the command line the following :
mvn install
After waiting for the application to compile, I open it using IntelliJ Idea (by opening the pom.xml file), I add Tomcat Server and I press run.
Then the IntelliJ Ide recompiles the application again.
Is there any way I can avoid this second compilation?
Thank you.
You should have tomcat configured as a server, and configure your module(s) to deploy at server startup. On the run configuration you will see a list of things to do before launch. It will probably say Make -- you can remove this if you need to.
However, you probably should allow idea to do this for you and really stop doing it on the command line. Idea can handle more complex build patterns for you. You should trust it.
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)
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.