I am working on a large project with about 60 different Eclipse projects. I am looking for a method of setting the JVM for all projects at once. I know that I can right click on each one, go to Build Path, and manually change it to a certain execution environment (or JVM or workspace default), but it appears that this must be done one at a time.
Thanks.
I don't know of any way to do it via the UI, but you could use a File search+replace to modify the .classpath files directly.
From the menu, toolbar, or keyboard shortcut open the File Search dialog. The text you want to search for, assuming your projects all use Execution Environment to specify their JRE libraries, is something like StandardVMType/JavaSE-1.7 (that's the text for the JavaSE-1.7 Execution Environment). Specify .classpath as the file name pattern, and the Scope you want, then click Replace...
In the Replace Text Matches dialog, specify the new Execution Environment text, for example StandardVMType/JavaSE-1.8. OK or Preview> to continue with the replacement.
Eclipse will re-build all the projects and once it completes they should all be referencing the new Execution Environment.
Related
When my Java application is run with "Run application" from Eclipse it needs to create files that persist across multiple runs of the application. Is it an acceptable practice to place these in the "target" directory? For example, workspace//target/database.db.
Are there events that cause eclipse to delete all files in the target directory?
If the target directory is not a good place to store these files where is a good place? It would be awkward to use System.getProperty("java.io.tmpdir") since the tmpdir is on a different drive and because I would need to mirror the structure of the workspace and project in the tmpdir.
Thank you
The target directory gets deleted when you clean your project (mvn clean). That makes this not the best place to store your data. You should better save it to System.getProperty("user.home"), or pass a directory as a program argument as SpaceTrucker mentioned in the comment, that`s also a good solution.
My recommendation would be the OSGi User Area (-user, intended for user-specific preferences etc.), or the OSGi Instance Area (-data, which is the default home of The Workspace). Take a look at this, and scroll down to "Locations", which explains a bit about these areas.
As for hazardous events, only -clean (the Eclipse arg, not the Maven target) and your deployment process come to mind. -clean should not touch persisted files but works on the internal caches, only, but you might want to try that out to be sure. Your deployment process might consist of "delete contents of installation directory" plus "copy new stuff to installation directory", which would wipe most of the areas which are by default placed inside the installation directory.
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 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).
I created a Wizard that when finished, adds two files at the Project Explorer.
One of them should be hidden, but when I press the Finish button at my wizard, Eclipse doesn't refresh the view automatically and it keeps showing the file. It just hide it when I press F5.
There's a way to force it to refresh the Project Explorer, right after I finish the wizard?
Another option is in eclipse
Go to Windows-->Preferences-->General-->Workspace--> and check the box for Refresh Automatically ("refresh using native hooks or polling")
If this option is turned on then the workspace resources will be synchronized with their corresponding resources in the file system automatically.
Note: This can potentially be a lengthy operation depending on the number of resources you have in your workspace.
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/reference/ref-9.htm
It sounds like you aren't using Eclipse resources API to make file system changes. You have two options:
The best option is to use Eclipse resource API instead of java.io when working with contents of Eclipse projects. See org.eclipse.resources plugin. Start with ResourcesPlugin.getWorkspace().getRoot().getProject( "name" ). Use IProject, IFile and IFolder API.
Alternatively, especially if your wizard is invoking code that isn't eclipse-aware, you need to invoke refresh after you are sure that all java.io based file system operations have been completed. Use refreshLocal() method, which is available on IProject, IFile and IFolder classes. For instance, the following snippet refreshes all contents of a given project. This is typically an overkill, so you will want to narrow down the scope as much as possible before invoking refresh.
ResourcesPlugin.getWorkspace().getRoot().getProject( "proj" ).refreshLocal( IResource.DEPTH_INFINITE, new NullProgressMonitor() );
Another option is to use "External tools" to call your tool, and check options to refresh and maybe compile target project/s in "Refresh" and "Build" tabs.
Run -> External Tools -> Externa tools configuration
You know how Eclipse reloads classes automatically running in Tomcat when resource files they depend on such as spring context files are updated so that you don't have to re-start Tomcat? How do I make a class dependent on a resource file so that Eclipse re-publishes it when the resource file changes? Eclipse would re-publish Spring classes when their dependent resource files are updated, but would not re-publish mine.
I'm not sure if it's Spring that's doing this for you. Are you developing in an IDE like Eclipse or Netbeans? What might be happening is as you make code changes your IDE is 'publishing' (i.e. re-deploying) your app code, so the app re-initializes every time the IDE publishes it, giving the illusion that Spring is reloading context files as they change.
This is useful with a small app but get's very annoying the larger your app gets.
If you're looking for this behavior for development, take a look at JRebel:
http://www.zeroturnaround.com/jrebel/
You say that you want the class to be republished ? Do you mean that you want the contents of the bean in the application context to be updated ? If that's the case, then what you can do is the following :
1) Write a file system monitor to monitor the resource(s) for changes. There's an example on google code
2) Have that file system monitor fire a custom Spring ApplicationEvent whenever the file / resource changes, providing that event the information for the resource, if necessary. ie the file name, the previous modified time, the last modified time, etc.
3) Have the bean you want to be updated implement ApplicationEventListener and reload the resource when it catches your file system monitor event.
A simple but working workaround can be to add an ant builder to your project. Steps to take:
read the article
here
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-93_project_builder.htm
create a simple ant file, that
contain a target, which touches
(simply changes the date of
modification) the dependent classes,
but nothing else (if you need help in it, let me know). Eclipse will provide you variables inside the script. You can print them easily with task. You will see the list in console.
right click on the project, and
press properties
open "builders" tab in properties
add your ant script as a builder to
the project
restrict the set of resources this
ant builder is called for. This can
be done in "build options" tab in ant
builder options. This way your
project will be fast, and the ant
script will only run for the changes
of the property file
set the set of resources (classes depending on properties) to refresh after running the ant script in "Refresh" tab
Set your ant script target to be called for "Auto build" in "target" tab. Others like after and before clean and manual build should be empty
You may redirect log of the ant script to file if you want. Otherwise it will open console view.
move your builder to be the first in the list of builders, since it must run before java builder
This is a workaround, and should work. It will have no bad side effect, since the content of java file will not change, and it will not affect the version control system, as well as the whole thing is workspace independent, if the ant script is in your project.