I am trying to setup sakai on my local machine, these steps when I reached the steps on Compile Sakai Source Code I was able to run mvn clean install with 'BUILD SUCCESS' output, but when I ran
mvn clean install sakai:deploy -Dmaven.tomcat.home=$CATALINA_HOME -Djava.net.preferIPv4Stack=true -Dmaven.test.skip=true
I got the error:
but when I ran the same command above with flag -X then
I got the error:
I have tried what may be the course of the error by going to https://cwiki.apache.org/confluence/display/MAVEN/LifecyclePhaseNotFoundException and also tried with the most of the fix suggested there (such as mvn install and mvn org.apache.maven.plugins:maven-compiler-plugin:compile. Sincerely speaking I don't know much about maven I just want sakai to work)
I have also searched youtube to see anything different from the installation guide that I followed, there seem to be only 2 videos for sakai and they followed guide closed to what I followed.
Try
mvn clean install -Dmaven.test.skip=true sakai:deploy -Dmaven.tomcat.home=/path/to/tomcat;
Replace /path/to/tomcat/ with the actual path to tomcat.
This works for me.
I have a spring-boot maven application I've been running locally as:
mvn spring-boot:run
I want to be able to run this in GitLab runner so that when I push the code to master, it automatically copies the latest up there and runs the application.
My GitLab runner is configured in shell mode right now, and I have inside of the .gitlab-ci.yml file a deploy task that runs just that:
mvn spring-boot:run
The issue I am running into is after the application starts, I can see that it is running... but it never shows as success or completed. It just hangs there (because the terminal is still running when you execute that command?)
Question is, is there an alternate set of commands I should be running to get my spring-boot application to update and run each time I push to master? What is it i should be putting into my gitlab-ci.yml (or other files). Note that I am not using docker or kubernetes... just shell.
Sample gitlab CI:
run-deploy:
stage: deploy
script:
- mvn $MAVEN_CLI_OPTS spring-boot:run
Trying nohup with that also fails.
- nohup mvn $MAVEN_CLI_OPTS spring-boot:run &
I believe you can use the run stage for this. It would look something like
run:
stage: run
script:
- mvn $MAVEN_CLI_OPTS spring-boot:run
You can see an example of this here.
Make sure you also define the stages to include run as the docs state
If no stages are defined in .gitlab-ci.yml, then the build, test and deploy are allowed to be used as job’s stage by default. (see stages)
Is the sample file you provided above your entire configuration file or only a snippet of it? If so, I can adjust my answer to fit your needs. Thanks!
I'm sorry this is so late. I've recently just had the same problem. Gitlab runner blocks on child processes, and any process in the child tree. This makes the disown command impossible since you can't get to it. Forking, and nohup also don't work.
The only solution I could figure out was using the at command https://linux.die.net/man/1/at
Basically I put my command in a script then did:
at now < my_blocking_command_script.sh
That successfully complete the runner and kicked off my program in the background.
I inherited Android Java-code in my company, without Gradle-files etc, and I want to be able to compile this on my dev-server (I program from a ChromeOS machine, hence a CLI SSH connection to a server where I do dev stuff). Now I found some Docker images like this one (which doesn't even have a working command line example) but I haven't managed to create an APK yet. What am I missing and how would you do this?
You have three steps to do:
Migrate your project to gradle.
It isn't too difficult since there are plenty of gradle project out there and you can try to follow them or just read "Migrating to Gradle" article.
Build project with gradle on local machine.
If you migrated properly you can build your project in terminal like:
./gradlew assembleDebug
but it might be also assembleDevDebug or assembleProdRelease which depends on your buildType and flavor in gradle. Check which assembles are available by running:
./gradlew tasks
Build project using Docker.
Based on image you linked:
docker run -t -i ksoichiro/android -v /path/to/project:/workspace -w workspace /bin/sh -c "./gradlew assembleDebug"
I am working on a project with Maven and Surefire plugin v. 2.11.
To run single tests I am using -Dtest=TestClass#testMethod and -DforkMode=never (without DforkMode=never I can't run tests because of lack of space for object heap). I got used to it and it was working for me fine.
So I am running:
mvn -Dtest=TestClass#testMethod test -DforkMode=never
and test is run fine.
But when I am running
mvn -Dtest=TestClass#testMethod -Dmaven.surefire.debug test -DforkMode=never
it just skips debug "waiting" part and the test is being executed (I am unable to connect using IDE).
mvn -Dmaven.surefire.debug test works for me fine with other project (where I don't need to care about fork mode).
Any ideas why the combination of forkMode=never and -Dmaven.surefire.debug doesn't work as expected?
The property maven.surefire.debug is setting the debugForkedProcess parameter of the surefire plugin.
The documentation for this parameter reads as follows:
Attach a debugger to the forked JVM. If set to "true", the process will suspend and wait for a debugger to attach on port 5005. If set to some other string, that string will be appended to the argLine, allowing you to configure arbitrary debuggability options (without overwriting the other options specified through the argLine parameter).
So it will only debug forked JVMs, which explains why it doesn't work when the tests aren't being forked. It isn't able to setup the debugging of a non-forked JVM process that is already running.
Use mvnDebug
What you can do instead is use mvnDebug, which allows you to debug the maven process itself - and as your tests are not being forked those as well.
i.e. instead of mvn -Dtest=TestClass#testMethod test -DforkMode=never you would execute mvnDebug -Dtest=TestClass#testMethod test -DforkMode=never. By default it will listen on port 8000 when it starts maven.
Is it possible to launch a debugger such as jdb from Maven? I have a pom.xml file that compiles the project successfully. However, the program hangs somewhere and I would really like to launch jdb or an equivalent debugger to see what's happening.
I compile using mvn compile and launch using:
mvn exec:java -Dexec.mainClass="com.mycompany.app.App"
I was expecting something like:
mvn exec:jdb -Dexec.mainClass="com.mycompany.app.App"
to launch the debugger but, as usual, my expectations are incongruent with maven's philosophy.
Also, I couldn't find any documentation (on Maven's website or google) to describe how debugging works. I suspect that I have to use some plugin.
If you are using Maven 2.0.8+, run the mvnDebug command in place of mvn and attach a debugger on port 8000.
For Maven <2.0.8, uncomment the following line in your %M2_HOME%/bin/mvn.bat (and maybe save the modified version as mvnDebug.bat):
#REM set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
More details in MNG-2105 and Dealing with Eclipse-based IDE.
Just as Brian said, you can use remote debugging:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 com.mycompany.app.App"
Then in your eclipse, you can use remote debugging and attach the debugger to localhost:1044.
I thought I would expand on these answers for OSX and Linux folks (not that they need it):
I prefer to use mvnDebug too. But after OSX maverick destroyed my Java dev environment, I am starting from scratch and stubbled upon this post, and thought I would add to it.
$ mvnDebug vertx:runMod
-bash: mvnDebug: command not found
DOH! I have not set it up on this box after the new SSD drive and/or the reset of everything Java when I installed Maverick.
I use a package manager for OSX and Linux so I have no idea where mvn really lives.
(I know for brief periods of time.. thanks brew.. I like that I don't know this.)
Let's see:
$ which mvn
/usr/local/bin/mvn
There you are... you little b#stard.
Now where did you get installed to:
$ ls -l /usr/local/bin/mvn
lrwxr-xr-x 1 root wheel 39 Oct 31 13:00 /
/usr/local/bin/mvn -> /usr/local/Cellar/maven30/3.0.5/bin/mvn
Aha! So you got installed in /usr/local/Cellar/maven30/3.0.5/bin/mvn.
You cheeky little build tool. No doubt by homebrew...
Do you have your little buddy mvnDebug with you?
$ ls /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
/usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
Good. Good. Very good. All going as planned.
Now move that little b#stard where I can remember him more easily.
$ ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
ln: /usr/local/bin/mvnDebug: Permission denied
Darn you computer... You will submit to my will. Do you know who I am? I am SUDO! BOW!
$ sudo ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
Now I can use it from Eclipse (but why would I do that when I have IntelliJ!!!!)
$ mvnDebug vertx:runMod
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Internally mvnDebug uses this:
MAVEN_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"
So you could modify it (I usually debug on port 9090).
This blog explains how to setup Eclipse remote debugging (shudder)
http://javarevisited.blogspot.com/2011/02/how-to-setup-remote-debugging-in.html
Ditto Netbeans
https://blogs.oracle.com/atishay/entry/use_netbeans_to_debug_a
Ditto IntelliJ
http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html
Here is some good docs on the -Xdebug command in general.
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
"-Xdebug enables debugging capabilities in the JVM which are used by the Java Virtual Machine Tools Interface (JVMTI). JVMTI is a low-level debugging interface used by debuggers and profiling tools. With it, you can inspect the state and control the execution of applications running in the JVM."
"The subset of JVMTI that is most typically used by profilers is always available. However, the functionality used by debuggers to be able to step through the code and set breakpoints has some overhead associated with it and is not always available. To enable this functionality you must use the -Xdebug option."
-Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp
Check out the docs on -Xrunjdwp too. You can enable it only when a certain exception is thrown for example. You can start it up suspended or running. Anyway.. I digress.
I found an easy way to do this -
Just enter a command like this -
>mvn -Dtest=TestClassName#methodname -Dmaven.surefire.debug test
It will start listening to 5005 port. Now just create a remote debugging in Eclipse through Debug Configurations for localhost(any host) and port 5005.
Source - https://doc.nuxeo.com/display/CORG/How+to+Debug+a+Test+Run+with+Maven
If you are using Netbeans, there is a nice shortcut to this.
Just define a goal exec:java and add the property jpda.listen=maven
Tested on Netbeans 7.3
If you don't want to be IDE dependent and want to work directly with the command line, you can use 'jdb' (Java Debugger)
As mentioned by Samuel with small modification (set suspend=y instead of suspend=n, y means yes which suspends the program and not run it so you that can set breakpoints to debug it, if suspend=n means it may run the program to completion before you can even debug it)
On the directory which contains your pom.xml, execute:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 com.mycompany.app.App"
Then, open up a new terminal and execute:
jdb -attach 1044
You can then use jdb to debug your program!=)
Sources:
Java jdb remote debugging command line tool
Why not use the JPDA and attach to the launched process from a separate debugger process ? You should be able to specify the appropriate options in Maven to launch your process with the debugging hooks enabled. This article has more information.
I use the MAVEN_OPTS option, and find it useful to set suspend to "suspend=y" as my exec:java programs tend to be small generators which are finished before I have manage to attach a debugger.... :) With suspend on it will wait for a debugger to attach before proceding.
I couldn't make any of the other solutions work and then I tried starting maven with the following.
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000 com.example.Main"
This worked for me and then I searched some more and found this other answer. IntelliJ can run Maven project in debug mode but ignores breakpoints
The fact is that my application is a spring-boot application. Now, the link referred to above may be right and the problem is that the spring-boot plugin creates a new fork that somehow invalidates the interaction between debugger and target app. I'm saying this because I got some info on how this may work from here
In any case, I don't know how the two solutions are related to each other. Is the first solution also preventing spring-boot from creating a fork??
Sadly I have no clue at the moment.
Here is how I do it.
For example:
mvn clean azure-functions:run -DenableDebug
Then, after it starts up, you'll see a link in the Terminal that says "Attach Debugger".
To me, that is the easiest way to do it.