I'm getting loads of warnings from generated files in my target folder (e.g. Java code generated from XSDs or surefire reports) that I can't fix, and it's hiding proper warnings in my source code.
Does anyone know of a way to tell Eclipse not to display warnings in certain folders, or just the "Derived" or target folders?
I've only been able to find the following two "almost" solutions:
The filter in the "Problems" view allows you to hide warnings containing (or not containing) a specific String in their description, but not part of their path or resource (file). Even if you could, this wouldn't be an ideal solution as the warnings would still be displayed on the project in the package explorer, hiding potential real warnings.
With the latest Eclipse version (Juno / 4.2) in the "Java Build Path" settings under the "Source" tab, you can "ignore optional compile problems" from each source folder. But this obviously doesn't work for cases where the folders aren't source folders (like the surefire reports). It does however fix one specific problem with warnings about generated sources, but might not in others, where the sources aren't (can't be) included as source.
It would just be nice if there was a way to tell eclipse not to display warnings about things in the target folder altogether, as it's often not very useful and might hide actual problems.
Cheers,
Svend.
It turns out you can do this fairly simply (at least in Eclipse Kepler).
Open up the Preferences panel, either for Eclipse as a whole or for the project. Select the Validation pane (if you're using the project preferences panel, you may need to enable project-specific settings). Now go to the validator that's causing you problems (in my case, it was the HTML validator, but it depends on what you're doing) and click the button to edit its settings, which pops up another dialog.
In this dialog you want to make sure that there is an Exclude Group that excludes Folder: target. If there's no exclude group at all, add one with the button on the right. Then select the exclude group and Add Rule… to bring up another dialog/wizard. You want to add a Folder or file name, and in the next step pick the target folder to exclude (using the Browse Folder… button) and keeping the checkbox for using just the simple filename checked. If you're adding a global rule, it doesn't matter which target folder you pick.
The OK/Apply back out of all the dialogs to apply the change you've made (or maybe add more exclusion rules). You'll need a rebuild so that the rule change is applied correctly, but that's straight-forward.
Folders that are not source folders are not compiled by Eclipse. So you should not have Java error/warning for those.
For source folder, you already have the solution ('Ignore optional compile problems' parameter).
Related
Situation::
Trying to search and open up a Java file. In a nest project.
And so, we have the file here, these 2 files the exactly same file,
but, when the project is nested inside, Eclipse search opens up the file that has no syntax highlight or source code link (ie: unable to ctrl click on the code).
(ie: Eclipse opens up the Java file as if the Java file is not on a build path)
(though, if I search directly on that nested project, instead of on the parent project, then things are fine)
I have to manually open up the file in the Project Explorer, to get the file with syntax highlight or source code link.
Ask::
How can I let Eclipse directly open up the Java file with syntax highlight (when I search on the parent project)
(so that I dont need to manually search & click all the way through)?
You seems to be using Maven and you probably imported your project in Eclipse as Maven project.
The problem with Maven and Eclipse is that usually Maven project are split as project aggregator (a pom.xml with only <module>) which m2e will import: such aggregator project use a directory hierarchy.
Eclipse, on the other hand, does not scan files as file system file, but as project related file: that's the main reason for your duplicate. The child project being contained in its parent, the same file is shown twice because for Eclipse, these are two distinct path.
And since for the parent project, the file is simply a regular file it does not offer anything beside syntax highlighting.
You can:
close each aggregator project one by one; for Eclipse, there are no really useful anyway.
don't import them (and I wish m2e-core would suggest it).
You could also create a bug or vote for this one which seems related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533440
Note that this also affect other screen such as Show Resources (which is the subject of bug 533440).
The workaround I am using::
workaround 01
Find the files in the nest projects as I did before, then get the class name, then ctrl shift t to search that class again.
Cons:
You have to manually copy and search the class name.
There are possible other classes with same name (and you have to tell which one you want to go to).
You will not be able to jump to the desire line.
workaround 02
Just search in the whole workspace. And directly open in the file in the child-project (ignore the results from parent-project).
Cons:
Time consuming when search the whole workspace (though, you can terminate it when you get the desire files, hopefully no missing results when you do that).
There are a lot duplicate / unnecessary results.
You may not want to search the whole workspace.
I'm posting this query after doing lots of googling and trying out different options for last few days. Is there an easy way to attach source in Eclipse? is the closest answer I found to my question.
From above post, I tried all solutions but each time Eclipse is opening .class file instead of .java file.
Eclipse Details:
Kepler Service Release 2
Build id:20140224-0627
Please let me know if this is a bug with Eclipse or if I am missing something.
If you are using Maven, try this:
Double click on your project in eclipse -> Maven -> Enable Workspace Resolution
This is most likely because Eclipse actually use the class file for declaring the item you have requested the declaration for, and not the source file you think it should be using.
The typical reason for this is if you have a jar file containing previously compiled classes on your build path before (or instead) of the project containing the source you want. This is very rarely desirable as it can take quite a while to discover that your edits do not take effect.
Examine your build path carefully and ensure it is as you want it to be.
Maven is likely supplying a Classpath Container to your project, and generating entries for the Java Build Path based on the pom.xml contents (the JRE System Library is another example of this). Its entries will not have source attachment unless the container decides it will, which is why the Installed JREs preference page offers to let you set Source Attachments. If the pom.xml has something like that, see if you can use it. If not, see if you can configure the Maven container from its context menu. Otherwise, you may simply be stuck.
I had this same problem: when I pressed F3 or tried to open Declaration (after right click) for any element, it took me to the bytecode .class file.
My solution:
I went to the project in Project Explorer:
right click on project name->Properties
Then in Porject Properties window,
Java Build Path->"Order and Export" tab
There I selected the folder with the .java files (source code), which was below the folder having the .class files -in my case "JRE System Library [java-11-openjdk-amd64]", and pressed 'Top' button on the right frame. Then the folder with source files moved to the top.
Finally, pressed "Apply and Close" button.
That solved my problem forever and ever.
The folder
I installed a plug-in which allows me to download the sources for a maven project.
I'm not by my develop machine right now, but I think it was this:
http://marketplace.eclipse.org/content/m2e-dynamic-sources-lookup#.U8gjGWIaySM
With this, you can select a project an have maven download the sources and make then available when you navigate the code in Eclipse. All without "leaving" Eclipse.
Check into your project modules the Java Build Path, look inside the Source tab and verify if you have "Allow output folders for source folders" checkbox flagged; in this case you just need to uncheck it and you will be able to see again the right source from java files.
This is related to the Call Hierarchy in Eclipse IDE.
If you are in a situation, where you're seeing duplicate methods inside the call hierarchy showing Members calling 'myMethod(...)', double-clicking on one of the listed methods may open the .class file instead of the .java file.
When this happens, the solution is to set the search scope in the call hierarchy to Project instead of Workspace.
After setting the search scope, you won't be seeing duplicate methods listed in the call hierarchy, and double-clicking on the listed methods will only open the .java files.
(Using Eclipse DevStyle Dark Theme)
I'm using Java annotation processing to generate a couple of Java source files. I enabled it on the project specific settings (Properties -> Java Compile -> Annotation Processing). The generation works fine and the classes end up in the .apt_generated source folder.
Unfortunately, I'm not able to commit the generated Java source files with Subversive to the svn server. If I selected the .apt_generated source folder and perform Team -> Add to Version Control ... the dialog doesn't list any files to commit. So far, I have been committing .apt_generated source folder from the command line. Can I customize this behavior? I wasn't able to find anything on this in the team preferences.
I'm aware of the option adjusting the headless build. Since my files won't be changed to often, I just would like to commit the generated files for the moment. Thank you!
The reason for this behaviour can be found in this thread: Subversive doesn't allow to commit "derived" resources. The folder used by the annotation processing and all contained resources automatically get the "derived" flag, which you can verify on their Properties->Resource page.
I'm in a similar situation as you wanting to commit generated files at least initially. There is a plugin that apparently makes it possible to override the behaviour of setting the "derived" flag, which I'm going to test now: AutoDeriv
Since this has been unanswered for over a year, I'll take a stab at it. I had a similar problem with Eclipse's .project and .classpath files, which I wanted maintained in Subversion.
I believe you may have to tell Eclipse not to ignore "resources." These are files that have extensions but no names (e.g. .project or .classpath or .apt_generated). From Eclipse's Project Explorer click on the View Menu icon (the upside down triangle icon). Then Customize View... then remove the check from the checkbox labeled .* resources.
Now that I've learned a bit more, I can ask a more direct question.
Scenario:
I have a Java project in IntelliJ Idea, with the end goal of making a standalone .jar capable of running on Windows or Linux, either run from the command line with java -jar jarname.jar or simply by being double-clicked like any normal, simple jar.
I've written a handful of classes, located in my src/package/name directory. However, one of my classes requires the use of an external class, i.e. a class not located in my source directory or is not part of Java's default set of .jar's in the JDK.
How do I go about configuring IntelliJ to build the .jar artifact AND include the necessary resources inside of it, with everything needed put in the proper place, so that my class can use the resource by an ordinary import statement? An answer given in example form would be awesome; I've almost figured it out, but there must be just one thing I'm not doing correctly.
Thanks for your time,
Yankee
Sources:
http://tukaani.org/xz/java.html
Viewing the directory structure of that source gives a better idea:
http://git.tukaani.org/?p=xz-java.git;a=tree
One does not simply package Mordor into their jar.
After much experimentation, I found a solution that, while maybe not the right way to do it, definitely works. The key is to:
Define your external library (a .jar in my case) as a module dependency.
Add your external resources as (what IntelliJ calls) an "Extracted Directory."
For the first item, go to File -> Project Structure. Click "Modules" in the Project Settings list on the left. In the list just to the right, you will see a list of modules (whatever they are) which belong to your project. Leave that alone, but make sure that it is highlighted/selected as the current module. What you want is the settings for that module, which will show in the window on the right. Go to the "Dependencies" tab. On the rightmost part of the screen will be a little green plus sign. Click that, choose "Jars or directories" and navigate to your relevant resource you want to bring along with your finished jar.
Note: don't be fooled by the check box that says "Export." Its only purpose is to cause endless pain and suffering as you wonder why the dependency isn't exported along with your jar. Always remember, the export box is trying to get you to click on it. It wants to be ticked :3
Next, add that resource as an extracted directory by going to File -> Project Structure. Then "Artifacts" in the Project Settings list on the left. Click the green plus sign at the top to make a new "Jar" artifact "From modules with dependencies." In the right hand window, under the "Output Layout" tab, click the little green plus sign and choose "Extracted Directory." Once again, browse to your precious jar.
You should now be able to successfully build a jar artifact that contains all the resources it needs to run as you designed it.
Here is a reference section on configuring external libraries as module dependencies - link. Regarding artifacts construction - it's possible to precisely specify its content (including dependency libraries content) - link.
Read How classes are found...
It is OK (expected that you) to ship your program in your own jar, and dependent 'libraries' as separate jars
You are expected to provide a way to run your program with the correct -classpath argument to the java command so that java can find both your jar, and the dependent jars... there are multiple ways to do that... see the link above.
Rolf
I have two copies of the same directory structure (basically, trunk and a feature branch) which both contain a Java project (call it ProjectX) in a subdirectory of the respective base directory.
I have painstakenly set up Eclipse the way I want it to work with regards to settings, colors etc.
Now, I want to be able to switch between working in either trunk\ProjectX or featurebranch\ProjectX. These are completely separate on disk (which is why I feel that the accepted answer to How to create multiple projects with same name in Eclipse? does not address my concern), but since they share the name ProjectX on disk, Eclipse doesn't seem to want to let me add them to the same workspace.
Working sets don't help me because the projects are not (yet) in the same workspace.
Removing and re-adding the projects very quickly becomes error-prone.
Making a copy of the workspace directory and opening that seemed to lose quite a few of my settings (colors, servers, etc.) (why that is is another interesting question) and as far as I could tell, there was no easy way to tell which workspace I am actually working in right now.
My question: What is the recommended way to deal with a situation like this?
I guess I am hoping for some way to define an alias of some kind, such that I can add trunk\ProjectX as TrunkProjectX and featurebranch\ProjectX as FbProjectX, then use working sets to switch between them.
Eclipse has a showlocation parameter:
eclipse.exe -showlocation
This will show the location of the workspace in the title bar.
I use an extra workspace for each branch. That way I feel secure, that I don't accidentally forget something and change trunk instead of branch.
For maven projects, that have same name use Advanced->Name templates (I prefer groupId.artifactId) while importing them into the same workspace
For eclipse projects, edit .project file and change <name> under <projectDescription>
I've used the following process, and it's worked for me:
Import both projects using the following steps:
Choose "File | Import" from the menus
Choose "Existing [Project Type] into Workspace", where [Project Type] is the type of project you're importing (e.g. Android)
Choose "Next"
Browse for your Project folder using the "Browse..." button
Before clicking "Next" or "Finish", change the "New Project Name" field entry to a unique name.
The project name is just a string in the .project file, so you could edit the file outside Eclipse before opening the project in Eclipse.