I have an Eclipse project where the Java build path is defined (in the project properties) to contain the folder "src" with certain inclusion patterns ("com/example/package1/**", "com/example/package3/**"). The reason is that, say, "package2" contains things that are irrelevant to this project but are relevant to some other project that shares its source tree.
I would like to try to use IntelliJ IDEA, but I can't seem to find the equivalent feature. Does it exist, or is there another way to do what I want?
Under a content root you can
-Include source folders (The folders containing the com package) with the blue folder button.
-Exclude folders with the red folder button. It will completely remove files from the intellij eyes. Not just to the java compiler.
-If this is not enough you have /setting/compiler/exclude where you can exclude packages or files individually but only to the compiler eyes. You can quickly add a file to these excludes by right clicking on a java compilation error. It may also work for compilers other than the java one.
In the Project Structure window, under the Modules section, Sources tab, you can mark some directories as "excluded" by selecting it and clicking on the "red folder" button.
Have a look at Preferences…/File Types/Ignored files and folders
This applies to all projects though.
Related
In Eclipse I have two maven projects A and B, where A is a parent for B. The directory structure is the following:
A/pom.xml
A/B/pom.xml
A/B/...
Then I use File search (Ctrl+H) to find any file in the project B. The search result window shows the file two times with different relative paths:
A/B/<my_file>
B/<my_file>
So, the same file is shown twice. Obviously, the first search result is reduntant. Is there a way to exclude these duplicate search results?
What I personally do to avoid this is marking each module in the parent project as derived (right-click on the folder > properties > Attributes: Derived).
Then when you perform a file search, uncheck "Consider derived resources" (I don't think it is checked by default) and you won't get the A/B/<my_file>.
The only inconvenience is that you must do this for each module, and each time a new module is added.
In an open resource window (cntrl+shift+R), click on the arrow on top-right and check "Filter Duplicated Resources". This worked for me.
Checking Window -> Preferences -> Maven -> Hide folders of physically nested modules (experimental) worked for me in Mars.1 Release (4.5.1).
After checking it I closed all projects within eclipse, deleted eclipse project files (.project, .classpath and .settings) and reimported my maven projects.
I had similar problem.
My solution for this problem was
Create eclipse "working set" of projects to search
Set this working set as option into search dialog
Search in it
Windows - Preferences - Maven - Hide folders of physically nested modules
I agree with Damon Horrell.
Go to Windows - Preferences - Maven - Hide folders of physically nested modules (make sure the checkbox is checked).
Note: Make sure to re-import the maven project into eclipse to see the changes.
Within the parent project, child ones were already visually hidden in my case, but still found through search and Ctrl-click links.
I solved this by using Resource filters:
Right-click (parent) project > Properties > Resource > Resource Filters
Click Add Filter..., select Applies to -> Folders and enter one child project's folder name, click OK
Repeat 2. for all child project folders
By the end, you should have something like this:
There is an ancient bug which requests Eclipse to support nested projects. Opened 2008, won't happen soon, I guess.
Since Eclipse doesn't support Maven's default nested module layout, you have to import each module individually which doesn't confuse Eclipse but it can confuse you as you can see in the search results. Similar things happen when you start to save launch configs in a module.
There are several possible solutions:
Get used to ignoring half the search results. Takes some discipline but no magic.
Make sure your root project doesn't contain anything important that you might want to open from Eclipse (i.e. move the parent POM to a new module which must be a child of the root project). Now you can close the root project.
Takes some discipline where to put things in your project and it's clumsy when you have to add new modules.
Use the flat multi-module approach. This is an extension to #2, it looks odd and there might be plugins that are offended by that. So if you use a lot of nonstandard plugins, you should check whether they like the new layout.
As a new joiner, still couldn't comment but I'd really like to add something to the best answer. It works! It not only removed the duplicate files for me (one from child module and one from parent module), it also removed the class files from parent module).
But it added the folder to my .gitignore which will cause problem for new files/directories added later. I just reverted the change to .gitignore and it still works in eclipse.
Find this answer to disable auto change of .gitignore
EGit and Eclipse modifies .gitignore file but it should not
You can solve this problem using a flat multi-module approach.
Caveats may apply if you're using the maven-release-plugin with a version control system other than Subversion.
In addition to "Hide folders of physically nested modules" mentioned, you could uncheck parent modules when importing Maven project:
I have read some questions on this around here but my tries at the answer have not yielded success. Here is the problem:
Package:com.me.a
Folder(under above package):b
Java class(under above folder):Myclass.java
The proper package structure is com.me.a.b, but eclipse thinks 'b' is a folder. When I right click on b and go to build-source, there is an option that says "use as source folder" which then does something totally unwanted - creates a separate folder with the entire package path as a source folder, and uses a default package:
Folder: com.me.a.b
Package: default package
MyClass.java
How do I solve this annoying issue?
PS: I am unable to use images which to give a better idea but being new here, there is a restriction.
You have project/com/me/a/b set as the source folder. Your build path looks something like this.
You need to set project as the source folder. Your build path will look something like this afterward.
this is very strange. packages are basically folders, so saying that you have package com.me.a with a folder in it named b is essentially the same as having package com.me.a.b.
Or there is something wrong with the Eclipse's workspace metadata for this particular project?
Try creating new project with such package and class in it see if it is any different?
The behavior you describe when choosing "b" as a source folder is expected: you are basically telling eclipse that this folder b is a source folder, a root folder for source java files. this is the default package, every sub-folder of this one is considered a different java package...
I just had this same problem with ONE folder between about 100 folders. The solution turned out to be righ click on the folder (in the package view), choose "Build Path", and then "Include" (Instead of 'use as a source foldre' as the OP did). After that the folder turned into a package.
What does the red exclamation point icon in Eclipse mean? There are lots of different search results on the Internet about "red exclamation point icons" and "red exclamation mark decorators" and "red bang icons," no doubt because lots of plugins and programming-related tools use red exclamation point icons. So, to be clear, this is the one I mean:
It appears as a decorator on projects in the Package Explorer view.
In my case, the icon went away when a missing build path variable was filled in. I'm using MyEclipse 9.0, but I don't think this is MyEclipse-specific. Other people on the Internet have reported that it has to do with other issues, including Subclipse, the .svn folder and moving files between working copies.
According to the documentation:
Decorates Java projects and working
sets that contain build path errors
In practice, I've found that a "build path error" may be caused by any number of reasons, depending on what plugins are active. Check the "Problems" view for more information.
It means there is a problem with the build path in your project. If it is an android project then it mostly means the target value specified in project.properties file cannot be found. This can also be caused because of other kinds of built problems. But it is shown mostly for built problems only. See here for more details. It is about built error decorater seen in eclipse.
An extract from that page:
Build path problems are sometimes easy to miss among other problems in a project. The Package Explorer and Project Explorer views now show a new decorator on Java projects and working sets that contain build path errors:
The concrete errors can be seen in the Problems view, and if you open the view menu and select Group By > Java Problem Type, they all show up in the Build Path category:
I also faced a similar problem when i tried to import Source file and JAR file from one machine to another machine. The path of the JAR was different on new machine compared to old machine. I resolved it as belows
Right click on the "Project name"
Select "Build path"
Then select "Configure Build Path"
Click on "Libraries"
Remove all the libraries which were referring to old path
Then, the exclamation symbol on the "Project name" was removed.
There can be several reasons. Most of the times it may be some of the below reasons ,
You have deleted some of the .jar files from your /lib folder
You have added new .jar files
you have added new .jar files which may be conflict with others
So what to do is we have to resolve those missing / updating / newly_added jar files.
right click on the project and go to properties
Select Java Build Path
go to the Libraries tab
Remove the jar file references which you have removed already. There will be a red mark near them so you can identify them easily.
Add the references to the newly added .jar files by using Add JARs
Refresh the project
This will solve the problem if it's because one of the above reasons.
I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly.
What I did was peculiar but somehow it fixed the problem. Pick any project and perform a fake edit of the build.properties file (e.g., add and remove a space and then save the file). Clean and rebuild the projects in your workspace.
Hope this solve some of your problems.
Make sure you don't have any undefined classpath variables (like M2_REPO).
I had the same problem and Andrew is correct. Check your classpath variable "M2_REPO". It probably points to an invalid location of your local maven repo.
In my case I was using mvn eclipse:eclipse on the command line and this plugin was setting the M2_REPO classpath variable. Eclipse couldn't find my maven settings.xml in my home directory and as a result was incorrectly the M2_REPO classpath variable. My solution was to restart eclipse and it picked up my settings.xml and removed the red exclamation on my projects.
I got some more information from this guy:
http://www.mkyong.com/maven/how-to-configure-m2_repo-variable-in-eclipse-ide/
The solution that worked for me is the following one given by Steve Hansen Smythe. I am just pasting it here. Thanks Steve.
"I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly."
Also be sure you dont have any closed project in the Projects tab ->
https://i.stack.imgur.com/StGEu.png
The solution that worked for me is the following one given..
I selected the particular project> right click >Build path>configure Build path> Libraries> I noticed that JRE system Library was showing(Unbound) hence..
selected that Library>click on Remove>click on Apply>click on add Library>JRE system Library>next>workspace default JRE>click on Finish>Apply>ok.
now you will not see these exclamation icon in your project.
I need to add external source code into my Eclipse project.
Project Properties>Java Build Path>"Link Source..." seems to be appropriate.
But it is necessary to add all the "source" folders of the folder that I link. It is a very complicated Folder structure, where "source" folders are located in different parent folders, but form the entire source code together.
I just hate the idea to manually navigate to every folder and add it. "Inclusion patterns" feature in eclipse seems to be suitable for the task, but I can't get its syntax and how to specify inclusion to add all "source" subfolders.
What do you guys do, when you have huge project built with ant for instance, where the source folders are right bellow the root project folder, for building classpath from source files ?
Putting entire project as a source folder is nonsense.
Putting separate folders as source folders can't be done if they are part of the package hierarchy and the only thing I could think of, is to copy the source folders into a separate folder and add it then as source folder which is weird but I don't know how else to do it.
Having to duplicate sources just because of the eclipse way of making classpath and also because of somebody doing stupid project structure
It's really pain in the ass...because the ant scripts are written for this structure.
Even if it was just one folder, it's a problem anyway. There must be included the upper folder to the source classpath which means it is included with all the crap around and also it means that package explorer is flooded with the packages.
example:
Instead of /project/src/java/utils where we can put src folder into source classpath...
there is project/java/utils + lot of crap like /project/docs is in the project as well.
The trick is:
An Eclipse project root directory is defined by where the .project and .classpath are.
Two options here:
Those Eclipse project files are located in the workspace (and the 'project', the one with 'java/utils' inside, is not)
Then you can make a linked folder within the Eclipse project to reference 'project', calling that linked folder as 'src', using it as your source folder.
The ant script remains right where it originally is (in the 'project' directory, along with all the other sub-directories)
Those Eclipse project files are located directly within the 'project' directory (along with 'java' and 'docs': don't.
Delete that Eclipse project (not its content, only its definition, that will only remove the .eclipse and the .classpath), and recreate anywhere else.
Then go back to 1.
For each source folder in eclipse you can choose which subfolders of it you want to include or exclude as a source folder (you can also use patterns). If I understand correctly, in your situation you can add the project root folder as a source folder and include only those folders that contain source. So in your example only "java" would be included.