To run my Maven application in Windows, I start the Cargo container with this command:
C:\code\myapp> mvn -P cargo.run
Then I use Ctrl-C to stop the Cargo container.
I want to do the same thing in Eclipse. I've created a run configuration for Maven:
This allows me to start the Cargo container, which I can view in the the Ecipse console:
At this point, Ctrl-C does nothing. I read here that Ctrl-C doesn't work inside Eclipse, but that I can stop the container with mvn cargo:stop. As you can see in the screenshot, I'm trying to use this command but it doesn't do anything. There's also a Maven console in Eclipse, but this command doesn't do anything there either:
If I use the Terminate button in the console window (red square), it leaves an orphaned JRE instance that I have to stop manually, and the container is still running.
Is there another window where I should be trying to use this command? Is there a better way to start and stop the container in Eclipse?
There is some information missing in your question, like your pom configuration that would help a lot to provide you the best answer possible.
The solution that will work for sure is to create a new run configuration for Maven on your project, as you did to launch your container with cargo, but instead of using the profile that you created to launch cargo, use the goal cargo:stop and then run this configuration.
It will launch the command mvn cargo:stop in another shell and will stop the container. And then you will be able to stop the console of the execution that launched cargo without having the orphaned JRE running.
A few years ago (about 8...) I tried to find a better solution when I worked a lot with cargo but could not improved this way to do it.
I recently started developing for Node.js/Express with Nodeclipse. I added a run configuration for package.json with goal start. This works as expected, the start command from package.json is executed (node ./bin/www). I can see this command in Eclipse's console view and I can see two node.exe processes appear in Windows Task-Manager. HTTP requests to http://localhost:3000/ are logged in the console.
However, klicking the red "Terminate"-Button in Eclipse's console view leaves the node.exe processes running. Subsequent attempts to start the app fail because the port is already in use.
I do not have this problem when I start the app with npm start in Windows cmd. Stopping the execution with Ctrl+C will also exit the node.exe processes.
This is my IDE-Setup:
Eclipse Luna SR2 (4.4.2) under Windows 7 x64 with jre1.8.0_45
Eclipse was setup this way: extracted eclipse-platform-4.4.2-win32-x86_64.zip (from here), installed Eclipse Marketplace Client, then installed Nodeclipse via Drag&Drop from nodeclipse.org
Node.js version v0.12.2 (for Windows x64)
express-generator (version 4.12.1) is installed globally
How can I make the Terminate button in the console view actually terminating the node.exe processes?
It seems that Eclipse only kills the npm script that is used to start up node. The thing is that Eclipse forcibly kills that script, giving it no chance to send any signals to the node.exe process.
This bug explains why this works this way.
Step 1:
Run command-line as an Administrator. Then run the below mention command. type your port number in yourPortNumber
netstat -ano | findstr :yourPortNumber
Red coloured circled area shows the PID (process identifier)
Step 2 :
Then you execute this command after identify the PID.
taskkill /PID typeyourPIDhere /F
P.S. Run the first command again to check if process is still available or not. You'll get empty line if process is successfully ended.
I have an SBT scala application that runs fine using "sbt run". However, this locks up the console, and I'd rather start it as a service/daemon so that I can use the console, and also so that I can add it to init.d to ensure that my application is started automatically on startup.
I can't seem to find a way to do this. Running "sbt run &" seems to hang the app in the background.
Does anybody know how to do this?
You could also jar up your application into a "fat" jar using either sbt-assembly or sbt-onejar.
This will make it an executable jar and easily runnable via java -jar jarname.jar.
We launch test/demo apps with SBT in init.d all the time:
#!/bin/sh
# test lift web app
case "$1" in
'start')
cd /home/demouser/wa/HTML5DemoLift231/HTML5demo/
sbt jetty run
;;
'stop')
cd /home/demouser/wa/HTML5DemoLift231/HTML5demo/
sbt jetty stop
;;
*)
echo "Usage: $0 { start | stop }"
;;
esac
exit 0
This just works - we have had no problems with it. It may be different with a non-web app though.
You can use GNU Screen for keeping it in background. Anyway I can't think a good reason to do that. Whouldn't it be better to package the application and run the generated binaries in the background?
Just type sbt runProd
And then press Ctrl+D
The process will be running as a daemon process.
What's the easiest way to debug Scala code managed by sbt using IntelliJ's built-in debugger? The documentation from "RunningSbt" from sbt's google code site lists commands for running the main class for a project or the tests, but there seem to be no commands for debugging.
Follow-up question: what's the easiest way to attach IntelliJ's debugger to Jetty when using sbt's jetty-run command?
There's a very convenient -jvm-debug flag in the official SBT packages for Mac, Linux & Windows. You can use the flag to specify the debug port:
sbt -jvm-debug 5005
Under the covers, this starts the JVM for SBT with the typical verbose debugging incantation:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
You now can run your code as normal, for example with the sbt run command.
Configuring IntelliJ to connect to the running code...
Now you connect IntelliJ to your running process using a Remote Debug configuration. Note that the upper 3 fields in this form, while scary, are just for you to copy text out of, rather than into (they're giving the verbose debugging incantation specified above, which -jvm-debug already takes care of for you) - the only configuration you can change is in theSettings section halfway down:
For ordinary debugging in IntelliJ, you can use an Application run/debug configuration in the usual way, regardless of whether you're using sbt to compile your code.
To connect to your application running in Jetty, you'll need to create a Remote debug configuration. When you do so, IntelliJ will give you a set of command line arguments for running the remote JVM -- something like
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Launch sbt with these arguments and then execute jetty-run. Finally, launch your remote debug configuration in IntelliJ. This thread might be useful.
I had some trouble with this too, so at the risk of being overly detailed, here's what I did:
SETUP
Create a run configuration for sbt jetty-run
Go to Run > Edit Configurations
Click the [+] icon and choose Scala Compilation Server
Enter whatever name you want, and click the "Run SBT Action" checkbox and select the SBT Action jetty-run from the [...]
Create a debug configuration for remote debugging
Go to Run > Edit Configurations
Click the [+] icon and choose Remote
Enter whatever name you want and copy the line -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 (make sure to click OK to actually create the configuration)
Set up sbt plugin to run the vm options above
Go to File > Settings > SBT
Paste the line -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 in the VM parameters box, after the ones that are already there
DEBUGGING
Set breakpoints as desired
Start the jetty web server by choosing the sbt jetty-run configuration you created above and choosing Run > Run or by clicking the green arrow
Start the remote debugger by choosing the remote debugging configuration you created above and choosing Run > Debug or by clicking the bug icon
This one works for me every time, and the only thing you need to set up is remote debugging in IntelliJ; I start up SBT with JVM parameters from the terminal in IntelliJ:
sbt -J-Xdebug -J-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
After that I can start remote debugging on localhost:5005
None of these answers or provided links worked for me, so once I figured this out, I figured I'd share...
including the background understanding I didn't have when I started...
This is based mostly on the instructions here just with additional explanation that carried me through it.
My Environment:
Scala 2.10.2, SBT 0.13, and IntelliJ 13.1
Background:
For whatever reason, using SBT to compile Scala in IntelliJ isn't integrated the way Maven projects are (which allow debugging really easily).
It appears from my understanding that when compiling with SBT, you're compiling in a separate process, therefore, you need to be remotely debugging.
What is Debugging?
Debugging is a mode you can run your JVM or app in that allows you to control the flow of code execution.
The Debugging Tool you use can then issue commands to the Debugging Engine that tells it "execute the next line of code then pause again" or "continue executing" or "get the value of the variable stored here in memory".
What is Remote Debugging?
Remote Debugging is debugging over a network connection (socket).
This network connection allows you to issue the commands to the Debug Engine from a remote machine.
This is useful for when you want to debug code that's running on a remote server, BUT
It's also useful for situations like Scala code running under SBT and launching via a web server, such as Jetty or Tomcat, separate from your IntelliJ environment.
Referencing the link above, the following explanations/modifications are useful:
Setup IntelliJ to launch SBT with the "enable debugging" JVM settings, including the port to use when setting up the network socket. (unchanged) add the named VM parameters to your IntelliJ settings.
Ensure your port number here matches your JVM settings from Step 1.
When you launch SBT, you need to do it from the SBT Console plugin (which is what you configured in Step 1). If you're running SBT outside of IntelliJ (at the commandline), you'll need to launch SBT with the same VM parameters from Step 1 (I didn't do this; so no instructions). After this step, SBT is now running (but your code is not yet) and the JVM is setup for Remote Debugging.
This starts the IntelliJ Debugging Tool, which connects to the JVM you started in Step 3.
Finally, you start the compilation in the SBT Console. You can do this with any compilation command, including a continuous compilation command. If continuous re-compile, the recompile will happen, but not while code execution is paused by the debugger.
I am adding another answer here, because I found this question when looking up a related problem: Debugging test classes using breakpoints.
I am using ScalaTest, and I typically run a suite using sbt's 'test-only' command. Now when I want to use the interactive debugger, I can do the following:
Create a new Run/Debug Configuration of type 'ScalaTest', put the main "Test Class:" name, and choose "Before launch: Run SBT Action 'test-compile'". That's it, you can place breakpoints now in the test sources, and run this configuration.
I've been struggling with debugging too on Windows with a Spray-can / Akka / Scala app built via SBT, using Intellij. Piecing together various suggestions, the simplest approach for me was:
Make sure you have sbt.Revolver in your project/plugsin.sbt file e.g.
addSbtPlugin("io.spray" % "sbt-revolver" % "0.7.1")
Set javaoptions in you build.sbt file:
javaOptions := Seq("-Xdebug", "-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005")
In particular use the suspend=y option. This will hold the app until you connect a remote debugger from Intellij
Set up a debugger configuration in Intellij via Run / Edit Configurations menu. Press the + button, select the "Remote" option. Make sure the entries match the javaoptions above, in particular the port address of 5005. Give the config a name like 'Spray'.
From your SBT console use the re-start command. You should see the 5005 port address in the feedback output.
In Intellij set your breakpoints.
From Intellij, select the Run \ Debug 'Spray'. This should connect to the spray-can web server. You should be able to see a lot of threads in the debug window.
Beware that some of the Get directives in Spray seem to get executed on start up but not repeatedly on calling the website.
File->Settings->Other Settings->SBT
VM parameters
-Xmx512M -XX:MaxPermSize=256M -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Run->Edit Configurations
Press + and then select remote
Press Apply
Now in the SBT console (Started inside by intelliJ) when you execute the command 'run' You will see "Listening for transport dt_socket at address: 5005"
Now press Run->Debug. You will see the debug menus below activated. It has two tabs Debugger and Console.
Use F7 to from next line to next
I chose suspend to be n. With it being y when I ran the run command it was stuck
export SBT_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5009
try this
For what it's worth Windows folk, edit %SBT_HOME%\bin\sbt.bat and locate the following lines of code:
:run
"%_JAVACMD%" %_JAVA_OPTS% %SBT_OPTS% -cp "%SBT_HOME%sbt-launch.jar" xsbt.boot.Boot %*
if ERRORLEVEL 1 goto error
goto end
then replace them with this code:
FOR %%a IN (%*) DO (
if "%%a" == "-jvm-debug" (
set JVM_DEBUG=true
set /a JVM_DEBUG_PORT=5005 2>nul >nul
) else if "!JVM_DEBUG!" == "true" (
set /a JVM_DEBUG_PORT=%%a 2>nul >nul
if not "%%a" == "!JVM_DEBUG_PORT!" (
set SBT_ARGS=!SBT_ARGS! %%a
)
) else (
set SBT_ARGS=!SBT_ARGS! %%a
)
)
if defined JVM_DEBUG_PORT (
set _JAVA_OPTS=!_JAVA_OPTS! -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=!JVM_DEBUG_PORT!
)
call :run %SBT_ARGS%
if ERRORLEVEL 1 goto error
goto end
:run
"%_JAVACMD%" %_JAVA_OPTS% %SBT_OPTS% -cp "%SBT_HOME%sbt-launch.jar" xsbt.boot.Boot %*
goto :eof
Best I can do to get same behaviour for -jvm-debug when seen in the Bash script launcher
NB. I don't think %SBT_HOME% actually exists outside this script, unless you created explicitly in you environment, but anyway you get the point :D
AttachMe IntelliJ plugin is potentially faster way off attaching the debugger without having to fiddle with port numbers:
AttachMe will attach the IntelliJ debugger automatically even if you
start your app from terminal (or any other way). You don't need to
trigger Attach to process action manually.
Blog post and readme have setup instructions, however I had to alter them a bit to get it working on my machine
Download installer.sh script from official repo
curl -o installer.shhttps://raw.githubusercontent.com/JetBrains/attachme/master/installer.sh
Give it executable permissions chmod u+x installer.sh
Run it with ./installer.sh
This should install the agent under /.config/attachme/agent.jar and create ~/.attachme file
Modify ~/.attachme to contain
AM_JDWP_ARGS="transport=dt_socket,server=y,suspend=y,address=127.0.0.1:0"
echo Using JDWP arguments ${AM_JDWP_ARGS}
export JAVA_TOOL_OPTIONS="- javaagent:/Users/mario_galic/.config/attachme/agent.jar -agentlib:jdwp=${AM_JDWP_ARGS}"
echo "AttachMe configured successfully"
Install corresponding Attachme plugin and restart: IntelliJ | Preferences | Plugins
Create Attachme run configuration: Run | Edit configurations... | Add new configuration | Attachme debugger registry | OK
After these one-off shenanigans, we can attach a debugger automatically by
Start Attachme run configuration
source ~/.attachme
Start application from terminal, perhaps, sbt "runMain example.Hello"
The debugger should automatically attach and stop at any breakpoint
I also got the same problem, I like to share how I resolved. By the way I am using Ubuntu 14.04 and IntelliJ 15.
In Setting -> SBT ->
Pasted below line in VM Parameters text box:
-XX:MaxPermSize=384M -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Opened Termilal in IntelliJ and run:
sbt -jvm-debug 5005
Note: you should see this line in terminal: "Listening for transport dt_socket at address: 5005"
Edit Configurations -> Click + -> Select 'Remote'
I. Give some name example: DebugMyModule
II. All needed configurations will be set automatically, But you just verify. In Command line arguments should look like this "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005".
III. In 'Search Sources in Module's Classpath' text box specify your module in which module your test cases are there.
IV. put 127.0.0.1 host instead of 'localhost'. 'localhost' not working for me.
Select DebugMyModule in Edit Configurations list box and click Debug.
Note: You should see Debug View opened and in Debug Console You should able to see "Connected to the target VM, address: '127.0.0.1:5005', transport: 'socket'"
Put breakpoints in few test cases in your Testclass.
Come to Terminal where you run "sbt -jvm-debug 5005" and run like below
project <your-module-name>
it:testOnly package.TestSpec
For example: com.myproject.module.AddServiceTest[Spec]
You can see debug started in your test case breakpoint.
Give a cent step by step regarding a relatively new version of Intellij (2020.1.4):
Configure Intellij
"Edit Configurations"
Add "Remote"
This new version of Intellij does not allow you to edit the string in the "Command line arguements", you can only edit the "Host" and "Port" above, which I leave it default; I only change the "module path" below to "root" (not sure if it's necessary)
Remote debug
Set your break point
Execute sbt command in command line, e.g. sbt -jvm-debug 5005 test
Immediately go back to Intellij and click on "Debug", it should show something like "Connected to xxx", then wait till it suspends at your break point
As per Roberto Tyley's answer above, but in Windows we also need to set the following environment variables after installing sbt:
SBT_HOME
C:\Program Files (x86)\sbt\
[or wherever sbt is installed]
SBT_OPTS
-Xdebug -runjdwp:transport=dt_socket,server=y,suspend=n,address=5005
[per RT's IntelliJ example]
Add to path: %SBT_HOME%\bin;%SBT_OPTS%
Then run the following in the command line within the project folder
"sbt run -jvm -debug 5005".
If this is working properly, the command line will initially output a line re
"Listening for transport dt_socket at address: 5005".
Set breakpoint in IntelliJ.
Open website in browser to trigger the debugger breakpoint e.g. "http://localhost:9000/".