I'm trying to analyze one Maven module of a Java project in Intellij IDEA using the Analyze->Inspect Code menu item. I have restricted the scope of the analysis to that project. When it runs the analysis, it gets to a phase called "Perform Backward Analysis" where it is looking at files outside of the module I ran the analysis on. Specifically, it is running the analysis on a large number of XML and HTML files that are used as part of the help documentation of the project and are not related to the code.
At the rate it is going, it is probably not going to finish the analysis this decade, so how do I either get Intellij to really only look at the files in the current directory, or turn off backward analysis, or exclude the XML/HTML files from the backward analysis so that it eventually finished?
When you go to Analyze->Inspect Code, the dialog gives you the option to limit to the "Current file" or the module that is active in the editor when you invoked it. You can also define a custom scope such as just java files or files in a particular package.. Click on the button with the ellipsis. In the dialog, click the help button for the syntax for defining scopes.
You can create a custom scope to do this. If you have a look at the custom scope dialog you'll find an option to exclude selected paths, or you can simply type a pattern, such as !*..*.xml.
Related
Scripts and styles for the project I'm working on get compiled and minified into single (enormous) files when the project is built. When IntelliJ goes to index everything, it spends a significant amount of time indexing the minified files, which are all but useless for the purpose of searching.
Is there a way to ignore specifically these files, and not just a directory?
I'm taking mostly a guess here, IntelliJ docs are notorious for being not-so-helpful on some topics.
Try marking the files as plain text:
When a file is marked as plain text, IntelliJ IDEA does not use it anymore for code completion and navigation...The reverse action is also available: you can return a file to its original type, using the Mark as action
Edit: After hearing that your files are dynamically created, I think I may have figured out a solution.
IntelliJ allows for the creation of Scopes, which allow you to exclude certain files from the project. You can then go to Editor -> Inspections and change the scope of each inspection from All Scopes to your new scope
IntelliJ allows you to configure the "File and Code Templates" in Settings.
This is a global setting, however I want different templates depending on which project I am working on (for example there will be different #author tags if its commercial / open source work, and version information varies by project).
Eclipse manages this on a per-workspace basis; how can I achieve the same thing in IntelliJ IDEA?
Unfortunately per project templates are not supported in IntelliJ IDEA. I recommend you comment-on/vote-for/track the feature request Make file templates per-project. (See UPDATE about this feature request below)
A few workarounds you can try...
Create a File Template for each project. Then when you create a new class, use the project's template rather than the standard "Java class" template. It will clutter up your template list a bit, and you have to remember to change from the default template when creating a new class (remember than inline search is available in the new class dialog when setting the type). But it is workable.
The copyright settings are done on a per project basis. Sometimes a need for a specific header can be met using the copyright utility (even if it is not an actual copyright statement). The options are pretty good for determining where it gets placed. The one shortcoming will be that while you can configure it to be a comment just before the class declaration, you can only configure to be a block comment or inline comment, not a javadoc comment.
Finally, a last option would be to write a live template for each project with the header information. Then after you create a class use the proper one to place the header information.
Hopefully those things will help while we wait for the feature to get implemented.
UPDATE
The above mentioned feature request to allow for file templates to be saved on a per project basis has been implemented in IDEA v14.1. It is currently (Feb 2015) available as an EAP (i.e. beta). It is scheduled for release at the end of Q1 2015.
I just created a project, and I notice immediately that I can't seem to right-click on my src folder and create a logical file group/folder within the project view.
In many IDEs, I can arbitrarily organize source files in groups/folders. These grouping help me organize my business process and data access layers appropriately.
How do I do the same in IntelliJ?
I'm not sure what the exact equivalent to what you're thinking is, or if there even is one.
IntelliJ has a notion of "scopes". Under the Project/navigation view, click the configure dropdown and choose "Edit Scopes...". From this window, you can define a pattern to include certain files from your project.
For instance, all of my DAOs are in packages called my.company.<feature>.persistence. I create a scope called "DAOs" with the pattern src[myProject]:my.company.*.persistence.*. Now when I choose "DAOs" from the Project view dropdown, I see a filtered view of the project. I haven't found a way to show that filtered view alongside other scopes at the same time, however.
These scopes can also be shared, and they can be used to narrow down searches. They are similar in many ways to Eclipse's working sets.
Many scopes are defined implicitly, like Test and Production, Changed Files, VCS changesets, etc.
I'm currently working an Eclipse plug-in to provide iPOJO manipulation support.
The principle of iPOJO is to modify the .class files generated by the Java compiler to inject some methods and to add/update an entry to the Manifest.mf file.
Currently, my plug-in provides a project Nature and adds a Builder, added at the end of a project builder list, that calls the iPOJO Manipulator.
I use it on PDE projects.
The complete process works but I have a problem :
When my builder has finished its job (and the building process), the whole building process restarts, erasing the output folder and calling my builder again.
If I don't add a safety trick, it makes the building process loop over and over.
As I work on IResource, an IResourceDeltaEvent must be sent at the end of the building process, so I think the best way to avoid that kind of problem is to hide the fact that the resource has changed.
To be clear, I'm looking for a way to modify the class files after a PDE build, without inducing a new build, and without disabling the workspace auto-build property.
Thanks for answers.
I am a little unclear as to what you are describing.
You mention that you want this to work for PDE builds, but PDE builds happen largely outside of the workspace using ant scripts. They do not use IResource, Builder, or IResourceDeltaEvent.
I am guessing that you don't really mean PDE builds, but rather the building of plugin projects inside of the workspace.
In general, Eclipse (JDT in particular) expects that it has complete control over the output folders. However, there is an option in Preferences -> Java -> Building -> Output Folder called "Rebuild class files generated by others". Ensure that this is disabled. Eclipse should not try to rebuild class files that you touch. If your builder only touches class files then it will not trigger other builds after it changes the class files. The only thing is that you need to be careful not to compile things twice (and I think this is the problem that you are describing).
Alternatively, it may be easier for you to implement a CompilationParticipant (and the org.eclipse.jdt.core.compilationParticipant extension point). This will allow you to know exactly when JDT calls a compilation and exactly what it compiles.
Additionally, you will be notified of reconcile operations (ie- changes in working copies that have not been saved). This may be useful for you if you wanted to manipulate files as-you-type.
I'm trying to integrate custom dynamic analysis tools to CDash. Such as KWStyle, CppCheck and Visual Leak Detector.
I'v figured out that I need to generate a DynamicAnalysis.xml file and submit it to CDash, from CTest scripts.
I think I know how to run the external tool as a part of the ctest script.
Either by using these variables to change how ctest_memcheck() works
CTEST_MEMORYCHECK_COMMAND
CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
CTEST_MEMORYCHECK_COMMAND_OPTIONS
or by running the tool from the execute_process() command.
But I'm a bit uncertain which one to use.
The main problem I think I have is, how can I extract errors from the output of the custom tool and include that information into the DynamicAnalysis.xml to submit?
The extreme solution i see is that i'd need to make a program that generates a valid DynamicAnalysis.xml file.
But the problem is that I don't know the syntax of the DefectList element in the XML file. I have found no answer from google and even the XML Schema for that file is unhelpful.
EDIT:
Looking at this:
http://www.cdash.org/CDash/viewDynamicAnalysis.php?buildid=987149
What draws my attention are the labels, especially the empty ones. I don't see how these would come from the DynamicAnalysis.xml file. Maybe it tracks any labels that have ever appearred? Can i create my own custom labels somehow?
Does CDash create the labels automatically, depending on the tool type? Does this block custom defect types?
I'm just guessing here, so the question is; can i create custom labels for my custom tool, just by generating a DynamicAnalysis.xml - file.
It occurred to me that the amount of different errors from CppCheck (static code analysis) is huge, compared to valgrind for instance. I'm not that certain that I should use the dynamic analysis. Maybe a custom build type (Continuous / Experimental / Nightly) thing would work better. Like this:
http://www.cdash.org/CDash/buildSummary.php?buildid=930174
I have no idea how to do this, i guess it requires meddling around with CDash code?
Which one would work better?
If you are using valgrind, you can simply set CTEST_MEMORYCHECK_COMMAND to the full path to valgrind, and ctest will generate the DynamicAnalysis.xml file for you from the valgrind output when you call ctest_memcheck.
The best way to understand the possible values that can appear in the DynamicAnalysis.xml file is to analyze the source code of CTest.
The file CMake/Source/CTest/cmCTestMemCheckHandler.cxx has the list of defect types in a variable named "cmCTestMemCheckResultLongStrings". Search through that file for references to that variable to see what the possible values are and how they are used to generate "<Defect/>" xml elements.
EDIT (for additional information):
You can also easily see what XML elements CDash is expecting by inspecting its source code. Specifically, the file "CDash/xml_handlers/dynamic_analysis_handler.php".
From what I'v learned so far, is that for a tool that runs on the tests made in the cmake script, the Dynamic Analysis is the thing.
For tools that run on the entire program, a custom Build.xml is the thing you need.
I found out that i can commit those files from the ctest_submit command by using the FILES parameter.
I also found out that you can add custom "build names" to the side of Continuous, Nightly, and others.
And that you can set the builds from certain machines to be automatically transferred under these.
The custom labels under DynamicAnalysis did come from somewhere in CDash, i can't remember where anymore.