Ctrl+Shift+G used to find references to the current selection within ALL projects in my Workspace.
Now is seems to only return references within the current Project.
Details:
I have 3 projects in the same database. 1 project is common code. The other 2 projects include the source folder of the common code on the build path. I prefer to link to common source instead of including the common code as a Project on the build path because then when I deploy by exporting WAR each project has its own self-contained version of the common code.
However Ctrl+Shift+G seems to work when I include the common code as a Project. So it looks like I need to do both. I just don't know why the searching results have changed. I did install JBoss Tools and as a result of Jboss needed to install a newer version of Indigo.
Similar issue, but no good answer.
EDIT:
Open two editors with a common class file, one from the linked source folder and one for the actual project folder. When the Ctrl+Shift+G is performed on the linked source, only references with in the project containing the linked folder are found. Ctrl+Shift+G from the actual common project finds references to all projects in the workspace, when those projects have the common project referenced on the build path.
The problem is when I am in a project and I control click a common code method I am taken to the linked source class file. So then when I do a Ctrl+Shift+G on that method, I miss all the other projects that reference this common method, because the editor contains the file from the linked source. This never used behaved this way and used to find all projects that referenced this method regardless of which file (linked or actual) was used.
I find the command..It is
Ctrl+ALT +G // search through out workspace
not
Ctrl +shift +G // searching within class/project
And one tip
Ctrl+shift+L to see all commands in Eclipse
This can occur if you are using Maven and your version numbers do not match. I had a dependent project with <version>1.0.0.RELEASE</version> that was being referenced in another project as <version>1.0.0-SNAPSHOT</version>. Fixing the mismatch so that versions were correct allowed CTRL-SHIFT-G to find the references in the workspace that it could not find before.
Related
I'm working on eclipse-kepler.
when I try to add external jars, they are added under the project and not under any folder (that is under the project),
Is there a way I can abbreviate (shorten/shrink) them so it wouldn't be so annoying?
Well, it depends on what is your issue.
If you would like to filter out libraries, there is a magical button, a white triangle on the top bar of the Package Explorer. There you can filter out all the libraries with a click so they won't be enumerated (see this screenshot).
If the issue is that they are included as external Jars (which I'd discourage, since it becomes harder to set up the project in a different environment both for you and others), simply create a lib folder, copy the Jar there and include it as simple Jar files (that way the .classpath file won't have any absolute paths).
Actually this feature is quite handy, it saved me a dozens of times. When there is a problem with a class you are using you can easily locate it by opening the type with Ctrl+Shift+T and linking it with the editor. It can go into the Jar files and show you where is it. When there is a Claspath conflict it can be a life saviour.
This issue is a variation on the one described here: Eclipse buildpath automatically taking all JARs of a internal directory
But instead of any local folder, I'd rather have a linked folder from another project be picked up automatically in the buildpath.
Basically, I have a main project in my workspace that holds directories lib, ext-lib that contain multiple jar files each. These jar files may be upgraded/removed or new ones added every few days.
I also have many other projects in the workspace that relay on the exact same (up-to-date) jars from my main project.
My goal is that as I modify the jars in these two folders in my main project, to have them as linked folders in all other projects and have those linked projects dynamically picked up as part of the buildpath of all those projects.
Any suggestion on how to do that in eclipse would be highly appreciated.
Unfortunately, the "dynamic directory" plugins people mention can not work with "linked" folders :(
Sincerely,
Guy
I would suggest creating a USER LIBRARY in eclipse and then using that in all of your eclipse projects.
Try going into preferences Java -> Build Path -> User Libraries and creating a new user library with all your jars. Then use this everywhere you need these jars.
See this page for more details.
Also, this page explains creating a user library in a bit more detail. There is also a use-case there which seems a bit more aligned to what you had in mind:
6.2.1. Linked Library Project
A useful hybrid strategy is to configure a user library that is also available as a linked folder in your Eclipse workspace. Follow these steps:
1.
Create a simple project in your workspace. Unlike Java projects, a simple project has no Java build path configuration in its properties. Use the command File > New > Project > Simple Project.
2.
Uncheck the option to use a default project location within the workspace folder and enter the path for your \eclipse-contrib\libraries folder (see Figure 6-8).
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
I am already using an open source GWT project (iServe) and I would like to integrate into it another open source GWT project (PetalsBPM), by which I mean being able to call it and reference its methods.
I have imported iServe in Eclipse (it has multiple modules) as separate Maven projects referencing its other and can run it successfully through Runas -> Web application in development mode.
If I do that and run the other project through the console as mvn gwt:run, I call initiate PetalsMBP through iServe. However, that means that the two programs have to run as is, without communication with each other.
I have also imported the second project into eclipse as a java project successfully (converting into a Maven one causes problems - various lifecycle configurations ones), but whenever I try to add to to iServe through Properties -> Java Build Path -> Projects, although it does not cause any errors immediately, I cannot launch iServe anymore. It produces the following error:
"Exception occurred executing command line.
Cannot run program "C:\Program Files\Java\jre7\bin\javaw.exe" (in directory "C:...iserve-sal-gwt-1.0.0-SNAPSHOT"): CreateProcess error=206, The filename or extension is too long"
Are my problems related to the fact that PetalsBPM is not a Maven project in Eclipse (I doubt it)?
Am I doing something wrong, i.e., this is not the way to reference a project from another one? should I add a reference to the first project's (iServe) gwt.xml file?
Is there a way to do what I want without having to wrap the second project as a jar and calling it from iServe? I would prefer not to, since producing a jar every time I make a slight change is not exactly efficient!
P.S: The second project is a regular GWT project with an entrypoint, not just a module. Should I remove this?
UPDATE: Trying to figure out the source of this error, I attempted to simplify the problem, so I performed the following moves:
I created two new simple GWT projects and tried to reference one
from the other. Worked fine
I referenced the project I actually want
to use (PetalsBPM) from the simple one I just created. Also works
fine.
I referenced the new simple project from the original one I
want to use (iServe). Also works fine.
Tried doing what I actually
want to do, copying the settings from 2&3. Produces the same error
"CreateProcess error=206, The filename or extension is too long" if
I reference PetalsBPM (does not when I remove it from the referenced
projects)
So, I tried switching workspaces. I created a new workspace in C:\, and moved the actual projects there. Still it did not work. :(
Any more ideas?
I met the same type of error "Create Process, error=206, path too long etc." a hundred times.
Then, I found a solution/explanation in google-groups, it solved my problem.
I post the content and link as it might help others.
This website (StackOverflow) really helped me a thousand times.
Thanks to you all !
solution/explanation :
(Response from Stephen Johnson)
(...) if you're using eclipse plugin go to Project | Properties, choose
Google \ App Engine \ ORM and only include directories that you have
classes that you want enhanced. By default it does the entire project
so that includes a lot of needless files. (...)
Link :
original post # google-groups
Read the exception message again. Somewhere along the way Maven is generating a path that is too long for (some) Windows API to handle, try moving your workspace to a directory straight below C:\.
I just tried "skolima" reply and it worked for me. In Eclipse I clicked File->Switch Workspace.
Three things to note:
After I created the workspace in "C:\workspace" I had to update my Project->Properties > Java Build Path > Libraries > Add External JARs...
I'm using Windows 7.
I'm using "Eclipse Java EE IDE for Web Developers"
I hope this others.
I have created a Dynamic Web Project in my Eclipse workspace. It is also a Maven project, and under SVN control. But in "Open Resource" (Ctrl+Alt+R) no file from this project appears, unless I check from the window's options (top right drop-down) "Show Derived Resources".
I have checked on some of the project's folders and they are not marked as "Derived".
I have two more (plain Java) projects in the workspace, and all the files from them are visible in "Open Resource".
Do you know what might be wrong with either Eclipse, the Maven plugin or Subclipse (the SVN plugin)?
I experienced a similar issue in Eclipse (Ganymede), when using the Maven and Subclipse plugins. I have not determined which plugin caused this problem, but I suspect that it is related to my pom.xml containing nested modules (ie. a <modules><module>main-module</module><module>integration-test</module>). These appear in Eclipse as nested folders with their own pom.xml files (I did not use the Multiple Projects plugin although I have installed it).
I assume that one of the plug-ins has incorrectly set the derived flag on these folders when I checked out the project by SVN and then updated the MVN dependencies and project settings.
When I right click->properties on the top-level nested module directories I can see the Derived flag is checked. By unchecking the derive flag on the module directories (and checking the derive flag on the target directories within each sub-module instead), it fixed the Open Resource functionality.
As the derived flag is inherited from directories, you may need to check all of your directories in the hierarchy to find the 'culprit'.
If it helps the plug-in authors, my top level module directories contain a hyphen '-' in their names. Maybe that is throwing out one of the plugins.
I think it is the maven plugin:
Jira issue
See also the notes for July 31, 2008 at the New and Noteworthy page for m2eclipse.
Several other nice links deleted because of restrictions of stackoverflow.
In fact, I think that somehow this is eclipse in its own right, as I don't have m2eclipse or using maven for this.
By default, eclipse uses /bin as the target directory. My situation is similar to having maven in the project in that the target directory was changed to lib/classes to accommodate an existing project.
I started seeing issues similar to what is reported here, and while searching for the problem, came across this solution. Eclipse somehow didn't "uncheck" the bin directory as no longer derived, so I ran into the same issues. I tried replicating it, but I couldn't.