I installed EclEmma for its source annotation abilities relating to code coverage, how it highlights code with various colors based on whether or not that code is hit during execution. I intend to use this information for debugging purposes. The default install adds a "launch with coverage" button, which is what I want. This works perfectly for the entry point into the program; that entire source file gets beautiful coverage information smeared all over it. Unfortunately none of the other project files get the same treatment.
When I go over to the new coverage tab I see my source folder structure and all of my source files are listed along with coverage percentages. This is nice, but I would really like it to add the coverage annotations to my other source files so that I can review code coverage line by line in the rest of my project. Presently even clicking on them in the coverage tab with the percentage sitting directly to the right opens the plain unannotated source file (well, unannotated besides Eclipse's normal annotations for Java code). How can I get EclEmma to add source code coverage information to all of my source files, not just the one containing the point of entry to the program?
I suspect that there is a simple fix that I am missing, but the best I can get from the relevant documentation is how to change the color of the annotations.
For reference I am using Eclipse 4.2.1 for Java development. My EclEmma installation is the one from the Eclipse Marketplace.
Thank you for your time,
-- Techrocket9
For unknown reasons the issue seems to have resolved itself. I can only conclude that the EclEmma does not require alteration to display source annotations for other files, and that a bug in my particular Eclipse install triggered the issue and that the bug was fixed in an Eclipse or EclEmma update.
Related
I'm with Jetbrains IntelliJ (or Android Studio if you prefer), and my project is built with gradle and some external java libraries from my company namespace. Thing is that is difficult to navigate trough classes as i cannot search text into the .jar files or resolve usages.
Do you have any idea of how to do this?, is there a plugin or something? a trick maybe?
Many thanks.
IntelliJ IDEA (as of 2017.2 or newer) knows how to decompile JAR files with no source attached, that is when you are in debug mode and you jump into the implementation. However this will not allow you full text search (such as looking for usages).
If it's just 1-2 JARs that you care for browsing, you may manually edit your Module properties in IntelliJ and add the source JAR files (that you need to download from your Library's website along with the binary JARs).
Another option is to use Maven, and have it download the source alongside with the binaries from the public Maven repository (if we're talking about open source libraries).
Yet another option, in an enterprise setting someone typically sets up an Artifactory (for instance https://www.jfrog.com/artifactory/ ), which is source for all the libraries and their source code.
If you use some up-to-date build script (for example Gradle), you can build an IntelliJ project with all the sources already linked in.
Hope this helps!
There is no easy way to do it. The only way to search for anything in library code is to attach source. The attached source can be code that you decompiled yourself, but IDE won't do it for you (but I think someone can write plugin that decompiles the whole library and attaches the decompiled source). So I guess that could be the "trick" you need to do.
Why is it impossible? I didn't write the IDE so I can't be sure why. But most likely the problem with finding text in jar files with no source attached, is that the text representation depends on the decompiler. There is no "best" way to decompile given class. Sometimes the decompilation may be even impossible (for example bytecode with a lot of goto/conditional jump instructions that don't nicely translate into loop/conditional constructs). In such cases decompilers can do anything from throwing an exception, putting raw bytecode, to just putting goto statements in the java code to at least show what the code is doing.
The only way that would allow to search in decompiled code (assuming you can't just download the code somewhere), would be to decompile it yourself (for example using the fernflower decompile, which is also used by intellij idea) and attach the decompiled source code.
While the above argument doesn't apply when finding usages of methods/fields, it's still not allowed, most likely because the IDE analyzes the source code to find usages, instead of analyzing the bytecode (compiled code).
We have a Java (7) project that uses Maven (3.2.1). We have a Jenkins (1.554) server, and we use it to run code analysis with SonarQube (4.3).
I have configured the default dashboard to show a few treemaps to visualize the test coverage in different parts of the project (using the link Configure widgets -> Category: Filters -> the "Measure Filter as Treemap" widget). The code gets analyzed totally fine, the test coverage gets recorded, the diagrams are colorful and everything is good.
Almost. We are using standard Maven folders for the code, and the package names are in the format "com.ourdomain.someapplication.subdivision.whatever". However, in the treemap diagrams on the dashboard all the packages are displayed as "src/main/java/com/ourdomain/someapplication/subdivision/whatever". As you can see in the attached screenshot, it makes the package names harder to read and the project becomes harder to navigate.
I am sure this is due to a faulty configuration on our part, but is it something to do with Sonar or Maven or Jenkins? Or something else?
Since SonarQube 4.2, all language analysers behave the same way and so indeed the path of all source files is relative to the project root directory. I known this might sound like a regression in your case.
I am using codePro tool to generate junit. Since I am using JDK1.4, I opted junit3 in codePro settings.
Despite me setting junit-3, the test cases are generated in junit-4 (with annotations)
The first screen shot shows that my setting shows my selection on junit-3
The second screen shot shows that test case generations are happening based on junit-4
Please guide me on this
I found it why it is happening.
Even though I opted junit-3, I was not having junit-3 jar file in my classpath and hence eclipse used junit 4 jar file from its plug-in folder
Now after including junit-3 jar file, am able to generate testcases with junit-3.
I am using Eclipse 3.4.2 to develop my code. As part of my project definition I reference a utility library to which I have attached the source code. So far, so good - I can see that source when I bring up classes from the library and while I am debugging.
Now however I would like to make a change to one of the classes while still retaining all the features of the Eclipse Java editor (specifically things like tool tips and quick fix). These features seem to work when I'm viewing the source (I can CTRL+LClick through method names for instance), but it is read-only. On the other hand I can explicitly open the source file which will allow me to edit it, but I lose all of the "smart" editing features.
I've recently switched to Eclipse from IntelliJ where this was possible so I'm hoping it is in Eclipse as well. Note that although I could simply include the code as a project in my workspace, I'd really rather not. The workspace is already quite large and I don't want to further slow Eclipse down by adding projects I rarely would ever touch.
I am not sure I get your question right. When you add a precompiled library to your projects build path (the JAR) and attach source to this JAR, Eclipse will show you the source code when you click on a .class inside the JAR. The same goes for the debugger, which will also allow you to step through the code lines in the source, if the classes in the JAR were compiled with line number information.
Now what you seem to want to do is modify the classes inside the JAR (the source view is just an overlay which can even be off, if you attach a different version of the source), which is not possible, because they are wrapped up in binary form in the JAR archive - even though Eclipse is smart enough to display them individually.
I guess you would expect your changes to be hot-swapped into the running program by the debugger. This can only be done through a recompile once you finished your changes. Usually Eclipse does that automatically when you save a Java source file. As your source file is however not part of the workspace (or an external folder explicitly declared as Java source) - it will not do that recompile and swap.
I'd recommend to include the source of your external library as a project in Eclipse and not worry about performance too much - I work with 3.4.2 every day and my workspace has about 45 open projects with several 10.000 classes and millions of lines of code. I assign a Gigabyte of RAM to the Eclipse VM and have no problems with that on a Core2Duo 2.6GHz machine.
I'm a NetBeans 6.5 user and am searching for a way of generating a list of methods/classes that are not used within a set project group.
I know I can right click on each method and select "Find Usages" but I'm looking for an automation to that process.
I'm willing to look at something that runs outside of netbeans, as long as it generates a list of cruft methods/classes.
Thanks.
Obfuscators like proguard can shrink your jars by removing unused methods/classes. Maybe it is possible to get a verbose output which contains the list of removed (hence unused) classes/methods.
Here you can find more information about finding dead code with proguard.
You can switch on the unused code rules in PMD (there's a NetBeans plugin), then run PMD over a whole project.
Use a test coverage tool to instrument your codebase, then run the application itself, not the tests.
Emma and Eclemma will give you nice reports of what percentage of what classes are run for any given run of the code.
There are several tools you can use to help find these and other problems:
PMD (mentioned by Bill the Lizard above)
Checkstyle
FindBugs