I understand how to run my application with command line arguments using the run configuration menu.
The problem I have is that no matter what I update these command line arguments to, eclipse does not reflect these updates when I execute the code.
so far I have set the arguments to:
test1.txt test2.txt dfs
and this will print:
args[0] = test1.txt
args[1] = test2.txt
args[2] = dfs
but if I update the arguments and re-run it, the arguments won't update
How can I "reset" the arguments and re-run the application using the updated arguments.
The above and below both function correctly and it was in fact eclipse that was causing me issues. The problem was resolved with a simple restart of eclipse.
Thanks all.
Click on Run -> Run Configurations
Click on Arguments tab
In Program Arguments section , Enter your arguments.
Click Apply
It is sure to work cause I tried it in mine right before I wrote this answer
There is a situation (bug) where modifying the Run -> Run Configurations arguments does not work, since the actual run configuration being executed is actually hidden from you.
So updating the visible one will not be reflected in your actual run.
Example:
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class EclipseRunConfigurationTest {
#Test
public void test() {
assertEquals("foo", System.getProperty("runProperty"));
}
}
Run it - it will fail.
Modify the run configuration using the method specified by Little Child. add "-DrunProperty=foo" VM parameter
Run it again - it will pass
Debug it, then switch to the debug view,
RClick the Junit launch -> Edit Rerun EclipseRunConfigurationTest...
Change the VM parameter to "-DrunProperty=bar"
Apply and Debug - it will fail
Open the Run/Debug manager again
Note that 'Rerun EclipseRunConfigurationTest' is not listed.
Note that the VM parameter is still "-DrunProperty=foo"
No amount of changing it makes the slightest bit of difference.
I shall file a bug report.
The above was run on Eclipse Kepler running on Fedora 20.
A small update in the solution given by Little Child above, to make it work with arguments having spaces in them.
e.g. first argument - abc def
second argument - ghi
third argument - jkl mno pqrs
In Program Arguments, give them like this using double quotes
"abc def"
"ghi"
"jkl mno pqrs"
If you don't give spaces it will take abc as first argument and def as second argument and ghi as thrid argument and so on..
For Eclipse Neon Users
Step 1: Click Run -> Run Configurations
Step 2: Click on arguments Tab.
Step 3: insert required arguments in VM Arguments.
Step 4: Click Apply
Step 5: Click Run.
Related
I'm trying to use Apache Commons Exec to run a git command which uses a regex.
When I form my CommandLine and print it out it looks like this:
[git, --no-pager, grep, --line-number, --untracked, --extended-regexp, "^\s*public void\s+(testFindByAdAccount).*", --, *Test.java]
However when I execute this, git returns no results, resulting in an exit code 1.
When I run this command manually though, it returns plenty of results and succeeds. Changing the --extended-regexp argument to just a string like testFindByAdAccount does yield results when run via Exec, so I think Apache Commons is doing something to the regexp argument making it invalid. Any ideas what is going on?
EDIT: Adding a reproducible example
Clone https://github.com/ragurney/min-example
Run gradlew shadowJar to produce jar file for project
Run the app with java -jar app/build/libs/app-all.jar
Note the output which shows the command printed fails with an exit code 1 (because there are no results returned by the git command)
$ java -jar app/build/libs/app-all.jar
HELLOOOOOO
WD::: null
[git, --no-pager, grep, --line-number, --untracked, --extended-regexp, "^\s*public void\s+(testAppHasAGreeting)\(\).*", --, *Test.java]
WD::: /Users/rgurney/Src/personal/min-example
Exception in thread "main" java.lang.RuntimeException: org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at min.example.App.lambda$runCommand$1(App.java:74)
at io.vavr.control.Try.getOrElseThrow(Try.java:748)
Running the command manually does produce expected results:
$ git --no-pager grep --line-number --untracked --extended-regexp "^\s*public void\s+(testAppHasAGreeting)\(\).*" -- "*Test.java"
app/src/test/java/min/example/AppTest.java:11: public void testAppHasAGreeting() {
I got a clue as to what's going on here when the sample you provided worked just fine on my Windows laptop but failed on my Linux desktop.
Once I made sure the git version wasn't the culprit (tested several versions between 2.17 and 2.39 on both machines), I figured the difference must be in the way different shells handle quoting. Specifically, the only argument here that has any potential quoting issues is the regex ("^\s*public void\s+(testFindByAdAccount).*"), which is added to the command line by commandLine.addArgument(regex);.
addArgument may look innocuous, but under the hood, it allows the CommandLine to handle the quoting itself (i.e., addArgument(String argument) calls addArgument(String argument, true). Since you've handled the quoting yourself, you should not allow the CommandLine to handle the quoting, and should explicitly call it with the second argument false. i.e.:
public static List<String> grep(String regex, String filePattern, String wd) {
CommandLine commandLine = CommandLine.parse("git");
commandLine.addArgument("--no-pager");
commandLine.addArgument("grep");
commandLine.addArgument("--line-number");
commandLine.addArgument("--untracked");
commandLine.addArgument("--extended-regexp");
commandLine.addArgument(regex, false);
// Here -----------------------^
commandLine.addArgument("--");
commandLine.addArgument(filePattern);
System.out.println(commandLine);
return List.of(runCommand(commandLine, wd).split("\n"));
}
This takes the quote-handling logic away and ensures the same code runs smoothly both on Windows and Linux (at least those I've tested).
I've got a simple setup with Cucumber feature files and Java step definition files.
feature.feature -> StepDefinition.java -> PageObject.java
Specifically:
STEP: Step definition file:
Given I am logged in as .... -> LoginSteps.java
And I am at the workspace -> WorkspaceSteps.java
And I start a new application -> WorkspaceSteps.java
And I accept -> AcceptPage.java - does not work.
- BUT:
And I accept -> AcceptPage.java - DOES work
As shown above, I'm using three step defintion files here. And cucumber recognizes the step definitions in both files. But it doesn't even attempt to run the "And I accept" step when it's defined in the AcceptPage.java file. If I move it to the WorkspaceSteps.java file, it runs fine.
There are no complaints about missing step definitions. In fact, there are no error messages, just orange coloring of the test results.
IntelliJ Run window:
Test results 4s462ms
- Feature: Complete application 4s462ms
- - Scenario: Budget 4s462ms
- - - And I accept 0ms
The .feature file:
Scenario: Budget
# Login/workspace
Given I am logged in as "12048746711"
And I am on the Workspace screen
And I start a new application
# Accept
And I accept
LoginSteps.java:
#Given("^I am logged in as \"([^\"]*)\"$")
public void iLogInWithId(String id) {
login(createPersonInfo(id));
}
WorkspaceSteps.java
#Given("^And I am on the Workspace screen$")
public void iAmOnScreenWorkspace() {
iAmOnWorkspace();
}
#Given("^I start a new application$")
public void startNewApplication() {
workSpacePage.applyForLoan.click();
}
AcceptPage.java
#Given"^I accept$")
public void iAccept() {
System.out.print("");
acceptPage.iAccept.click();
}
The step pointing to the iAccept() method on the AcceptPage.java doesn't run. Even when I put a break point on the System.out.print() line and debug, it doesn't stop or even get there.
But If I move the entire iAccept() method into the WorkSpace.java file, everything works.
Any ideas?
Of course, I've invalidated IntelliJ's caches and restarted. I've even tried creating a brand new Steps file, containing a new step with a new name. It's the same: The cucumber test refuses to go anywhere except to the WorkspaceSteps.java file. This is starting to look completely idiotic, hillarious and absurd.
It turns out the solution was really silly. For some reason, IntelliJ had removed the top package from the Glue in the configuration, and instead added specific packages. So, when a file not belonging to those packages was used, it was just ignored without further explanation. Deleting the specific packages and entering the top package solved the problem.
I apologize for the simplicity of this problem.
I'm trying to use a program called ChromHMM to analyze some biological data. I try and run the program according to the instructions but can't seem to enter the arguments correctly.
Here is an example:
E:\ComputationalAnalysis\ChromHMM>java -mx1600M -jar ChromHMM.jar BinarizeBed
chromosomelengthfile=\CHROMSIZES\hg19.txt inputbeddir=\Donor1 cellmarkfileta
ble=\Donor1\cellmarkfile.txt outputbinarydir=\firstoutput
It returns just this:
usage BinarizeBed [-b binsize][-c controldir][-center][-colfields chromosome,sta
rt,end[,strand]][-e offsetend][-f foldthresh][-n shift][-o outputcontroldir][-p
poissonthresh][-peaks][-s offsetstart][-strictthresh][-t outputsignaldir][-u pse
udocountcontrol][-w flankwidthcontrol] chromosomelengthfile inputbeddir cellmark
filetable outputbinarydir
In the manual it says the 4 arguments at the end are the only ones required to run. Does anyone know what I'm doing wrong? I'm trying to do this from the windows command prompt
try removing the name of the argument and the equals;just pass the value. so in your example you would have the following.
E:\ComputationalAnalysis\ChromHMM>java -mx1600M -jar ChromHMM.jar BinarizeBed
\CHROMSIZES\hg19.txt \Donor1 cellmarkfileta \Donor1\cellmarkfile.txt \firstoutput
I have the following line in a batch file.
java Client "127.0.0.1" 9876
It contains the name of my java class and two arguments. My application requires these arguments to run properly.
Is there any way to pass these arguments when running the application in eclipse? It would make debugging a lot easier. Of course I could resolve the problem by using the values of the arguments in the code but I'm curious.
Instead of just hitting the "Run" icon, select the dropdown box next to it, and choose "Run Configurations". Find your application (or create a Run Configuration for it) and put the command line arguments in the "Arguments" tab. See the docs for more information. It should look like this:
See the run configurations. You can specify arguments. You can even prompt the user for arguments, along with defaults:
${string_prompt:host:127.0.0.1} ${string_prompt:port:9876}
The first prompt is host, with default value 127.0.0.1 filled in. Second pop-up has the prmpt port, with 9876 filled in
Right-click on your project.
Go to Debug As > Debug Configurations or Run As > Run Configurations.
Click the tab that says Arguments.
Enter in your Program Arguments
Click Apply or Debug
Want to add something like, how to add multiple parameters.
Right-click on your project.
Debug > Debug Configurations
Go to Arguments tab.
Enter in your Program Arguments, each separated by a new line. (e.g 3 arguments in attached image)
Click Apply or Debug
Hope it helps.
From "Run" go to debug/run configurations. Click the tab called "Arguments". You can give the program arguments there.
Run configurations > Arguments tab. Just put "127.0.0.1" 9876 in the program arguments.
Run-> Run Configurations->Arguments->Enter your arguments separated by space->Apply->Run
Ensure that the right project name and it's main method are selected under "the Main" tab under run configurations
this work for me, in public static void main method.
public static void main(String argv[]) throws Exception {
int port_com = 2;
boolean debugMode = true;
int socket = 6789;
HasarMain hasarMain = new HasarMain();
// Check if a command line argument exists
if(argv.length != 3){
System.out.println("Missing, Port - socket - debugMode!");
System.exit(0);
}
port_com = Integer.parseInt(argv[0]);
socket = Integer.parseInt(argv[1]);
debugMode = Boolean.parseBoolean(argv[2]);
Run-> Run Configurations->Arguments->Enter your arguments separated by tab->
${string_prompt:argv:"2" "6789" "true"}
I have a bat file with the following contents:
set logfile= D:\log.txt
java com.stuff.MyClass %1 %2 %3 >> %logfile%
when I run the bat file though, I get the following:
C:\>set logfile= D:\log.txt
C:\>java com.stuff.MyClass <val of %1> <val of %2> <val of %3> 1>>D:\log.txt
The parameter is incorrect.
I'm almost positive the "The parameter is incorrect." is due to the extraneous 1 in there. I also think this might have something with the encoding of the .bat file, but I can't quite figure out what is causing it. Anyone ever run into this before or know what might be causing it and how to fix it?
Edit
And the lesson, as always, is check if its plugged in first before you go asking for help. The bat file, in version control, uses D:\log.txt because it is intended to be run from the server which contains a D drive. When testing my changes and running locally, on my computer which doesn't have a D drive, I failed to make the change to use C:\log.txt which is what caused the error. Sorry for wasting you time, thanks for the help, try to resist the urge to downvote me too much.
I doubt that that's the problem - I expect the command processor to deal with that part for you.
Here's evidence of it working for me:
Test.java:
public class Test
{
public static void main(String args[]) throws Exception
{
System.out.println(args.length);
for (String arg : args)
{
System.out.println(arg);
}
}
}
test.bat:
set logfile= c:\users\jon\test\test.log
java Test %1 %2 %3 >> %logfile%
On the command line:
c:\Users\Jon\Test> [User input] test.bat first second third
c:\Users\Jon\Test>set logfile= c:\users\jon\test\test.log
c:\Users\Jon\Test>java Test first second third 1>>c:\users\jon\test\test.log
c:\Users\Jon\Test> [User input] type test.log
3
first
second
third
the 1 is not extraneous: it is inserted by cmd.exe meaning stdout (instead of ">>", you can also write "1>>". contrast this to redirecting stderr: "2>>"). so the problem must be with your parameters.
This may seem like a stupid question, but is there an existing D: drive in the context that the bat file runs in?
Once I had a case where a bat file was used as the command line of a task within the Task Manager, but the Run As user was set to a local user on the box, giving no access to network drives.
Interpolated for your case, if the D: drive were a network drive, running the bat file as, say, the local administrator account on that machine instead of a domain user account would likely fail to have access to D:.