When I'm working in IntellijIDEA how do I tell it to ignore a class file that may have problems and I want to leave dormant for a while?
It will throw errors when I compile whatever class I am working on until I fix the first "dormant" class.
I have tried adding my class to a bogus package but Intellij doesn't like that either because the path doesn't match.
Settings | Compiler | Excludes, add your WIP files there:
You could use Refactor -> Rename File..., and change the file extension.
That is set at the inspection level
Configure Current File Analysis CTRL + SHIFT + ALT + H
I have profiles with differing inspection levels setup loosely based on the phase of my project builds ... I'd suggest taking a look at Customizing Inspection Profiles.
To ignore specific files during compilation you can add files individually or recursively in via the project settings panel ...
Configure Compiler Analysis CTRL + ALT + S :: Compiler => Validation
A bit late, still
If all your files are in the same package, then right-click on the package in the Project tool window and pick "Mark directory as -> Excluded".
All the classes inside the package won't be compiled. You can cancel exclusion any time you want the same way.
Usually, only the classes that are used in the application are actually compiled.
In your case, I would guess that it's only broken unit tests that hinder the compilation (as opposed to any other Java classes in the /main folder).
The reason is this: When running all unit tests in a package or source folder, IntelliJ searches and includes all the files that appear like unit tests by default: those with Test or Suite in the class name, but also those annotated with #Test or #Suite.
So the easiest way to exclude your test is to create a third source folder, call it /ignore, and not mark it as a source folder in IntelliJ. You can then drop any file you don't want to include in your compilation there temporarily, and drag it back to its original folder when you want to continue working on it. Beware, though: You will get only limited tool support if you open and edit the file within an unmarked source folder, so it should really be used for "parking" only.
You could also change the file extension, as the other answer suggests, but then IntelliJ will also change its handling of the file in other respects, not just during compilation.
Also, if you're using JUnit 4, you can always annotate any single test method, or the entire test class, with #Ignore, and it will be skipped during the test run. This requires the class to be formally correct, though, i.e.: no compile time errors.
P.S: You need to actually move the test to a different folder, if you really want the package to change - not just edit the package declaration. Otherwise, a non-matching declaration will also be considered an error.
Related
I want to run the "Analyze -> Inspect Code" task on some generated code and see if there are unused methods ("unused declaration" warnings).
I tried to create a custom "scope" called "With Generated" and explicitly include the paths to the generated directory and the regular source tree. It shows that there are 51 files (including both my regular project files and the generated files). I believe it is processing this directory correctly (I assume the regular inspector would ignore the generated directory).
I removed the #Generated annotation from the generated java files, was not sure if this was preventing some analysis.
I manually added a few declarations like this to the generated file AND to a file in my source tree to make sure there are unused declarations that the inspector should find. I am not 100% sure that the generated methods (created from a third party library) would be considered unused (I don't explicitly call them in my code, but perhaps the analyzer determined they are reachable purely inside the generated code...). So, I put in methods which I know are never used to make absolutely sure there should be something found if the files are processed.
public int foobar() {
return 1;
}
I then ran the inspect code command and choose the custom scope.
It does find unused declarations in the regular source tree.
But, it does not find unused declarations in the generated files, even those I have added manually.
Any ideas how I can inspect generated source code?
If it matters, I'm using the https://github.com/apollographql/apollo-android/ project to generate code from a schema and query as per their instructions. An example of an Android project would be here: https://github.com/apollographql/apollo-android/tree/master/apollo-sample/src/main/graphql/com/apollographql/apollo/sample
First of all let me put you in context. My main background is Java and I'm working in Python since 2 months ago. I don't know if the approach it's wrong due to my Java background and in Python has a different solution or it's just a technical ignorance problem.
In Java often you have a packaging structure like:
project
|___src
|___main
| |___java/MyClass.java
| |___resources/properties.file
|
|___test
|___java/MyClassTest.java
|___resources/properties.file
Thus, when you execute this from tests (with Maven or IDE):
this.getClass().getResourceAsStream(resourcePath);
Either Maven or IDE loads the test path in the classpath, making test resources available rather than the ones within the main package.
Conversely, when previous line is executed as main, only the resources within the main path are loaded to the classpath.
My question is: Is there any mechanism in Python to simulate this feature? Does Python have other ways to manage resources depending on the execution path?
I think mock might be what you are looking for. It allows for 'mock'ing out external functions to limit the test to strictly the unit under test.
This could mean changing some of the philosophy around some of it. For example, if you want to test that a function is reading a file correctly the filename would get passed to the method as a parameter. In your unit test for the function, pass in a different filename from your test folder.
In another test mock out the open call to the os to check that the method responds as expected when the file is not there, or cannot be opened, or whatever other mis-behaviors you want to test for.
No, Python has no deployable like Java has (WAR, JAR, etc...). You will run your code directly from the source, so, just read the file.
In the Java context, you do not have the code when it is deployed. So every resource should be package inside a file (JAR or WAR).
If you want to find the file in the current folder, look this question.
I don't know very well Python but you are right to ask yourself the question
as separating test and application code makes part of good practice to have a robust/reliable application and tests.
The pytest (a known test framework for Python) documentation explains in its best practice guide the two ways (separating and not separating the test code from the application).
Here is the part referencing the isolated layout :
Choosing a test layout / import rules
pytest supports two common test layouts:
Tests outside application code
Putting tests into an extra directory outside your actual application
code might be useful if you have many functional tests or for other
reasons want to keep tests separate from actual application code
(often a good idea): setup.py
mypkg/
init.py
app.py
view.py
tests/
test_app.py
test_view.py
...
This way your tests can run easily against an installed version of
mypkg.
Note that using this scheme your test files must have unique names,
because pytest will import them as top-level modules since there are
no packages to derive a full package name from. In other words, the
test files in the example above will be imported as test_app and
test_view top-level modules by adding tests/ to sys.path.
If you need to have test modules with the same name, you might add
init.py files to your tests folder and subfolders, changing them to packages: setup.py
mypkg/
...
tests/
init.py
foo/
init.py
test_view.py
bar/
init.py
test_view.py
Now pytest will load the modules as tests.foo.test_view and
tests.bar.test_view, allowing you to have modules with the same name.
But now this introduces a subtle problem: in order to load the test
modules from the tests directory, pytest prepends the root of the
repository to sys.path, which adds the side-effect that now mypkg is
also importable. This is problematic if you are using a tool like tox
to test your package in a virtual environment, because you want to
test the installed version of your package, not the local code from
the repository.
In this situation, it is strongly suggested to use a src layout where
application root package resides in a sub-directory of your root:
setup.py
src/
mypkg/
init.py
app.py
view.py
tests/
init.py
foo/
init.py
test_view.py
bar/
init.py
test_view.py This layout prevents a lot of common pitfalls and has many benefits, which are better explained in this
excellent blog post by Ionel Cristian Mărieș.
https://docs.pytest.org/en/latest/goodpractices.html
We're creating a new project in IntelliJ and must have something wrong because when we right click on a directory, select New and then get the context menu, Java based options are not shown. Currently get things like File, some HTML options, XML options.
We have assumed so far it's something we haven't configured correctly in the Project/Module configuration. The new module we are talking about is part of a multi module project. We created it using a Maven web archetype.
Any help configuring the project nature?
Edit: The answer is basic: 'That moment when you realise somethings not working because you haven't been clicking 'Apply'... :) We had a good laugh at ourselves when we discovered this'
The directory or one of the parent directories must be marked as Source Root (In this case, it appears in blue).
If this is not the case, right click your root source directory -> Mark As -> Source Root.
This can also happen if your package name is invalid.
For example, if your "package" is com.my-company (which is not a valid Java package name due to the dash), IntelliJ will prevent you from creating a Java Class in that package.
you need to mark your directory as source root (right click on the parent directory)
and then compile the plugin (it is important )
as result you will be able to add classes and more
If you open your module settings (F4) you can nominate which paths contain 'source'. Intellij will then mark these directories in blue and allow you to add classes etc.
In a similar fashion you can highlight test directories for unit tests.
Project Structure->Modules->{Your Module}->Sources->{Click the folder named java in src/main}->click the blue button which img is a blue folder,then you should see the right box contains new item(Source Folders).All be done;
I will share another interesting point. If you try to create a package with the reserved keyword then it will be treated as a normal directory and not a package. I was having this issue where I was creating a package named import and it was converting that to a directory.
Another possible solution is that the project name is not acceptable. For example, creating a project with spaces in the name does not block the project creation but the proper sources are not marked and when those are marked manually, I still was unable to create classes. Recreating the project with hyphens (-) instead of spaces corrected the problem for me.
Make sure you are not creating a package name which is same as predefined keywords in java like enum, int, long etc.
In my case I was trying to create a class under "enum" package. As soon as I changed package name to "enums" I was able to create class in it.
Had this issue too. Invalidating Caches/Restart did the trick for me. Please upvote so the the IntelliJ folks take this more seriously. This gives the IDE a terrible UI/UX experience.
https://youtrack.jetbrains.com/issue/IDEA-203100
There is another case where 'Java Class' don't show, maybe some reserved words exist in the package name, for example:
com.liuyong.package.case
com.liuyong.import.package
It's the same reason as #kuporific 's answer: the package name is invalid.
If you just created your project, let IntelliJ finish indexing your project.
You need to mark your java directory as Source Root ,
Right Click on Java directory
Select Mark Directory as option and click on the sub menu option Source Root
Most of the people already gave the answer but this one is just for making someone's life easier.
TL;DR
You must add the test folder as source.
Right click on java directory under test
Mark it as Tests
Add src/test/java in Test Source Folders
Thats it, IntelliJ will consider them as test source.
I would like to know What are the difference between folder-structure and package used in Eclipse IDE for Java EE development.
When do we use which one and why?.
Whats should be the practice
create a folder structure like src/com/utils and then create a class inside it
create a package like src.com.util and then create a class inside it
which option would be better and easy to deploy if i have to write a ant script later for deployment ?
if i go for the folder-structure will the deployment is as easy as copying files from development to deployment target ?
If you configured stuffs correctly. Adding a folder inside src, is same as adding a package from File > New Package.
So, it's up to you, whatever feels comfortable to you -- add a folder or create a package. Also, when you put stuffs under src the package name starts from subfolder. So, src/com/naishe/test will be package com.naishe.test.
Basically there is no difference, both are the same.
In both the cases, the folder structure will be src/com/utils.
and in both the cases, you will need to mention
package com.utils;
as first line in the class
Since it doesn't have any difference practically, it won't make any difference to ant script.
"Packaging helps us to avoid class name collision when we use the same class name as that of others. For example, if we have a class name called "Vector", its name would crash with the Vector class from JDK. However, this never happens because JDK use java.util as a package name for the Vector class (java.util.Vector). So our Vector class can be named as "Vector" or we can put it into another package like com.mycompany.Vector without fighting with anyone. The benefits of using package reflect the ease of maintenance, organization, and increase collaboration among developers. Understanding the concept of package will also help us manage and use files stored in jar files in more efficient ways."
check out http://www.jarticles.com/package/package_eng.html for more information on packages
create a package like 'src.com.util'
That sounds like a mistake. The package name should be 'com.util', and 'src' is the name of the source folder.
Other than that, I fail to see what the difference is between your two choices. The result is the same, right? Just different steps in the GUI to arrive at it. The wizard to create a new package in Eclipse is just a wrapper around creating the appropriate folder hierarchy within a source folder.
You don't need to create empty packages at all, you can directly create classes (the package will be created automatically if it does not already exist).
A package is automatically "source folder" where folder is just a normal folder.
When you compile an Eclipse project, all files in source folders are compiled but not in regular folders (unless those regular folders a)
folder structure or to be specific source folder in eclipse is meant just for eclipse but package is universal irrespective of any editor..
I am creating an eclipse plugin, and I need Class object of selected file, not IType. Is it possible, and how is the best way to do it?
Edit: when I think about it, the best way is to add it like run as (like junit, profiler, or other plugins are doing). I suppose they must have access to Class (if X is class in question), because they are running it's functions. So how to create plugin that has "run as " action, and get live object?
In an eclipse plugin, you will, for instance, get the selected file through an IAction.
(it represents the non-UI side of a command which can be triggered by the end user. Actions are typically associated with buttons, menu items, and items in tool bars.)
From there:
IResource selectedResource = ResourceUtils.getSelectedResource();
IResource The workspace analog of file system files and directories. There are exactly four types of resource: files, folders, projects and the workspace root.
From its type, you can cast it into an IFile, which gives you acces to its full path (getFullPath())
Eclipse uses an abstract representation of the object being selected, be it a file (IResource) or be it a Java Type (IJavaType). As it is not required for a source file to be compiled (e.g. disabling auto build), there does not necessarily be a .class file or a Class object for the code being edited. Hence, there is no correct way to get a "Class" object from the a selection in the user interface.
However, as yesterday mentions, you could rely on the fact that the Eclipse builder mechanism will always compile the source files immediately and thus a .class file exists. To reach to this .class file at runtime, you would need to create a dynamic class loader for the project or start a runtime VM. I tried that and it does work, but it is a very unstable approach and can lead to various hard to trace failures.
The classname of an IType "curIType" can be retrieved through
curIType.getFullyQualifiedName()
That's the simple part. But then you have the problem, that this class does not have to be in the classloader of your plugin (if it's a class of one of the userprojects, it's seldom part of your classloader). So calling Class.forName(classname) won't do any good.
I had a similar case and did (in a first attempt) solve it by creating an own thread with an own classloader, which included all libraries of the current classloader and all libraries of the type's project. That's neither a short code nor a simple one and I've already refactored it. It's much simpler to get all information out of the IType and not using the classes anywhere in the plugincode.