I see that in the cobertura-maven-plugin, I can configure my instrumentation with both excludes and ignores. What is the difference between these two?
Really sorry, but parroting the horrible documentation is not helpful. You quoted:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
This inconsistent paragraph starts by stating "...to ignore certain classes by passing in 'ignore' regular expressions.", then a second sentence later, "This will ignore any calls to any method that matches the ignore regular expression."
Well, so which is it? Does "ignore" ignore classes or methods? The command-line reference seems to imply ignore is ignoring a line of code based on RegEx matching (I wish that was true):
None of these interpretations works for <ignore> in the maven plugin.
Experimentally I have found that <exclude> is the way to exclude at the class-level. I have not found a way to exclude at a granularity less then class. However, what they also don't tell you is that <exclude> expects a relative filesystem path, not a Java package.class expression, which means <exclude> expects e.g. one/two/three/Myclass.class, rather then "one.two.three.Myclass".
Ignore and exclude really function nothing alike. Exclude will remove a file from Cobertura's scan. Ignore will remove all usages of a class from contributing to line coverage.
Consider the following code snippet:
public class Foo {
public void someMethod() {
Bar bar = new Bar();
}
}
If you configure <exclude>Foo.class</exclude>, then the entirety of the Foo class will not show up on your reporting.
Semi-confusingly, if you configure <ignore>Foo.class</ignore>, then Foo will still show up on your reporting, but uses of Foo in other classes will be ignored.
If you configure <ignore>Bar.class</ignore>, then the scan of Foo will ignore the line in which Bar is initialized.
To really make that stick, let's talk about why you would use ignore. Let's say that there is an object (such as a Logger) that you do not want to show up in the code coverage scan of any classes. Ignore allows you to do this.
The maven plugin does not contain any documentation for this configuration options (but they are included in the docs). The ant cobertura doc contains the following documentation:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
See also: https://github.com/cobertura/cobertura/wiki/Ant-Task-Reference#cobertura-instrument-task
Related
When I applied pattern in JDL, the generated entity classes has #Patternannotation, but the value for that annotation is not the exact pattern which applied in JDL.
For example, if I've defined patterns as pattern('/[^\\s]+.*[^\\s]+/') and in java
it reflects as
#Pattern(regexp = "[^\\\\s]+.*[^\\\\s]+")
If you noticed in java class, there are 4 (slash) which indeed should be 2 only. Because of this functionality is getting failed.
It looks to me like you are trying to use regex control characters in your pattern, which do not need to be doubled up in your JDL: see https://www.jhipster.tech/jdl/entities-fields, especially the part under "Regular Expressions" where it says: "/.../ the pattern is declared inside two slashes... \ anti-slashes needn’t be escaped"
So it's acting correctly. Since you have double-backslants in your JDL, Java is correctly interpreting it with quadruple-backslants. Your solution is just to use single backslants in your JDL, as per the documentation.
How does one convert an ASTNode (or at least a CompilationUnit) into a valid piece of source code?
The documentation says that one shouldn't use toString, but doesn't mention any alternatives:
Returns a string representation of this node suitable for debugging purposes only.
CompilationUnits have rewrite, but that one does not work for ASTs created by hand.
Formatting options would be nice to have, but I'd basically be satisfied with anything that turns arbitrary ASTNodes into semantically equivalent source code.
In JDT the normal way for AST manipulation is to start with a basic CompilationUnit and then use a rewriter to add content. Then ASTRewriteAnalyzer / ASTRewriteFormatter should take care of creating formatted source code. Creating a CU just containing a stub type declaration shouldn't be hard, so that's one option.
If that doesn't suite your needs, you may want to experiement with directly calling the internal org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFlattener.asString(ASTNode, RewriteEventStore). If not editing existing files, you may probably ignore the events collected in the RewriteEventStore, just use the returned String.
We would like to understand a couple of legacy job-dsl scripts but don't know what "slash operator" means in this context (as it cant be division):
def command = (shells.first() / command)
We have tried to look it up in several Groovy books but only found the trivial solution that it means 'division'.
It's an XML Node operation, to return a sub-node of a XML node, or create it if it doesn't exist. Probably the command node under the first of your shells nodes here.
Groovy allows operator overloading, so it is the same "division" operator, just redefined somewhat. This is common (but also controversial) in other languages allowing operator overloading, but does allow for richer DSLs.
Having had a quick look at (an old copy of) the JobDSL source, it seems that they're doing it using a class NodeEnhancement, notably this JavaDoc:
/**
Add div and leftShift operators to Node.
div - Will return the first child that matches name, and if it doesn't exists, it creates
...
**/
I'm using PHPStorm EAP version PS-138.940.
I have code as follows:
Config(__NAMESPACE__."\ObjectsToIdentifiers")->oldTables = array('Modules\Old\Model\DeviceStock','Modules\Old\Model\ProductPack','Modules\Old\Model\SpareStock','Modules\Old\Model\ConsumStock');
The functionality is irrelevant in this case. Important are the entries in the array. These are fully qualified class names - the leading / is omitted, but adding it doesn't solve my problem. I want to be able to click inside one of the string literals, press Ctrl+B and be redirected to the class definition.
Note that this works in ExtJS (javascript framework) where a string literal like
"MyApp.namespace.view.MyComponent"
will take me there.
Is there any way to manually configure this or do I have to submit a feature request. If so, how can I do that?
Update 1:
I created a feature request on JetBrains Youtrack: http://youtrack.jetbrains.com/issue/WI-24262
Came across this question looking for something in Storm that would let me quickly convert "\Some\ClassName" to Some\ClassName::class like an Intention or plugin, but so far have found nothing.
i'm surprised the ::class static property hasn't been mentioned. It produces the FQN of the Class, and resolves from import aliases.
The following should be a legit rewrite that the IDE can resolve:
// Same __NAMESPACE__, so no prefix needed
Config(ObjectsToIdentifiers::class)
->oldTables = [
Modules\Old\Model\DeviceStock::class,
Modules\Old\Model\ProductPack::class,
Modules\Old\Model\SpareStock::class,
Modules\Old\Model\ConsumStock::class
];
// or, if you import the classes:
use Modules\Old\Model\DeviceStock as OldDeviceStock;
// you can refer to
OldDeviceStock::class;
Unfortunately, right now if you jump-to-definition of the alias, Storm won't take you to the actual class, but where the alias is defined. Not terribly helpful, but gets you halfway since the actual class is right there.
this is a fairly general question about whether people should be using brackets on method calls that take parameters or not.
i.e.
def someFunc(def p) {
...
}
then calling:
someFunc "abc"
vs...
someFunc("abc")
Is this just a question of consistency, or is there specific use cases for each?
It's primarily a question of consistency and readability, but note that Groovy won't always let you get away with omitting parentheses. For one, you can't omit parentheses in nested method calls:
def foo(n) { n }
println foo 1 // won't work
See the section entitled "Omitting parentheses" in the Style guide.
There's no specific case where you must remove them, you can always use them. It's just prettier to leave them out.
There are cases where you can't do that (where you could confuse a list/map parameter with a subscript operator for instance, nested calls, or when the statement is an assignment), but the general rule is that the outmost call can have no parenthesis if there is no ambiguity.
(deleted several lines, as I've just received notification that there is a post already with that info)
Groovy 1.8 will allow even more cases to omit parenthesis, you can check them out at
http://groovyconsole.appspot.com/script/355001
"an empty pair of parentheses is just useless syntactical noise!"
It seems to me that they are encouraging you to use parenthesis when they serve a purpose, but omit them when they are just "noise"