I tried to figured out how to disable assertions via the tomee-maven-plugin.
By default, the console output of the launched TomEE JVM informs me:
Command line argument: -ea
Therefore, to disable assertions, I made a good guess and tried -da as args (see below)
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>${tomee.plugin.version}</version>
<configuration>
<tomeeVersion>${tomee.version}</tomeeVersion>
<tomeeClassifier>plus</tomeeClassifier>
<debug>false</debug>
<tomeeHttpPort>8282</tomeeHttpPort>
<debugPort>5005</debugPort>
<args>-da</args>
....
Good news: Assertions are in fact disabled, however, I'm wondering about args precedence here as the console output still prints:
[main] sun.reflect.DelegatingMethodAccessorImpl.invoke Command line argument: -da
[main] sun.reflect.DelegatingMethodAccessorImpl.invoke Command line argument: -Dtomee.force-reloadable=true
[main] sun.reflect.DelegatingMethodAccessorImpl.invoke Command line argument: -Dtomee.jsp-development=true
.... some more lines
[main] sun.reflect.DelegatingMethodAccessorImpl.invoke Command line argument: -ea
As you can see -da is printed first and afterwards -ea yet at runtime Assertions are disabled.
My questions are:
How is precende defined in this context?
Is this configuration robust so that -da always has precedence over -ea in this setting?
FYI: Using tomee-7.0.2 at the moment.
ea will always be just before classpath and the main (Bootstrap) since we try to not override provided values (typically for system properties). Issue here is da != ea so we didn't detect it is the same.
Related
I am using ceedling for unit testing in a firmware I am working on.
I would like to see all command line option ceedling uses when invoking the compiler.
I tried to use the option --trace, but so for I have not found any difference.
ceedling test:all --trace
try:
ceedling verbosity[4] test:all
If you are on a Windows machine, the command line args can be intercepted like this:
Create a little command line tool ShowArgs.exe that displays the given command line args in a message box.
Create a registry key in SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe whereas Foo.exe is the name of the compiler without the path.
Add a value with name debugger and value "" including the quotation marks, e.g.
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe\debugger="C:\Temp\ShowArgs.exe"
Now ShowArgs.exe acts as the debugger for Foo.exe and is called instead. The first argument is the path to Foo.exe, all other arguments are the ones you are interested in.
my question is very simple, how do I make all warnings become errors on SwiftLint? (without manually configuring each rule separately)
To integrate SwiftLint to your project, you normally need to add a Run Script Phase, as described by the doc.
If you used the CocoaPods installation, this script would look like:
"${PODS_ROOT}/SwiftLint/swiftlint"
That is where you can customize the command line options. In your case, you may want to use:
"${PODS_ROOT}/SwiftLint/swiftlint" lint --strict
The warnings will still be displayed as warnings, but an extra error will be given, preventing running or archiving:
Command /bin/sh failed with exit code 3
That is the desired error.
One drawback with "--strict" flag is that it won't show which line has a Warning.
You can pipe the output and replace "warning" with "error" by adding:
| sed "s/warning:/error:/"
the whole command will look like:
"${PODS_ROOT}/SwiftLint/swiftlint" lint --strict | sed "s/warning:/error:/"
then Xcode will show all SwiftLint warnings as errors.
You can make every swiftlint rule throw an error by enabling --strict
swiftlint lint --strict
Alternatively, you can configure each rule of swiftlint if you are using a config.yml file so that only certain rules throw an error.
swiftlint lint --config 'config.yml'
In the config.yml file simply add the configuration for the rule you want to throw as an error.
implicit_return:
severity: error
I believe this will work for any swiftlint rule. This is useful if you are looking to gradually adopt a stricter approach to linting.
I recently discovered the Failures into Break-Points - option from googletest using the command line option gtest_break_on_failure or by defining the GTEST_BREAK_ON_FAILURE environment variable.
I gave it a try using gtest_break_on_failure. From command line, I saw no effect (to be honest I had the glimpse of hope that VS2010 would be registered as debugger and somehow magically would pop up and point to the error source).
Using it in the VS environment as command line argument a failed assertion triggered a break but the call stack did not include the test method that caused the failure. I found the work around to step (F10) until I reached my test code, but that does not really seem to be convenient.
Is it somehow possible to use the option from command line ?
Has anybody a recommendation how to get the correct call stack in the environment?
From VS, you can add --gtest_break_on_failure to the Command Args in the target's Property Pages, then just run the exe without stepping over.
From the command line, you should be able to run the Debug executable with the flags --gtest_break_on_failure --gtest_catch_exceptions=0 and this should allow you to break into the MSVC debugger when the test fails.
I recently discovered the Failures into Break-Points - option from googletest using the command line option gtest_break_on_failure or by defining the GTEST_BREAK_ON_FAILURE environment variable.
I gave it a try using gtest_break_on_failure. From command line, I saw no effect (to be honest I had the glimpse of hope that VS2010 would be registered as debugger and somehow magically would pop up and point to the error source).
Using it in the VS environment as command line argument a failed assertion triggered a break but the call stack did not include the test method that caused the failure. I found the work around to step (F10) until I reached my test code, but that does not really seem to be convenient.
Is it somehow possible to use the option from command line ?
Has anybody a recommendation how to get the correct call stack in the environment?
From VS, you can add --gtest_break_on_failure to the Command Args in the target's Property Pages, then just run the exe without stepping over.
From the command line, you should be able to run the Debug executable with the flags --gtest_break_on_failure --gtest_catch_exceptions=0 and this should allow you to break into the MSVC debugger when the test fails.
We are building multiple targets with xcodebuild, but from the command line, all we get is failures like so:
The following build commands failed:
CompileC MOAIFmodExChannel.o ../../src/moaiext-fmod-ex/MOAIFmodExChannel.cpp normal i386 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)
If we run the builds in Xcode, it tells me information about why the build failed. How can we view this from the command line? Is there a log file where this would get dumped or can we provide some kind of flag to xcodebuild to enable that?
xcodebuild outputs a summary at the end of the build that mentions which commands failed. That's what you quoted in your answer. The actual error message will be visible in the output at the point those commands ran. You can scroll up in the output until you find an earlier occurrence of each command (e.g., CompileC MOAIFmodExChannel.o …) to see the error messages.