I am using Eclipse Ganymede.
I have a project open and call a static method of a class in another project, which the current one references.
I close the current project, open the referenced library's project, change the method return type, and rebuild its jar. (It's set to build automatically, but I tried explicitly rebuilding all anyway.)
When I go back to the original project, it still thinks that the static method returns the old type. What am I doing wrong?
P.S., "refresh" on the context menu doesn't fix it either.
The problem may depend on how the first project references the class file in the second. If it has a hard-coded classpath to a jar produced by the second project, you'll need to make sure that jar file is properly updated where it is linked from.
Since you control both projects, ideally the first project would be dependent on the second project as a "project dependency", not as a jar dependency (then it would automatically sync changes between the two)
You can find a list of those projects (and add to them) by right-clicking on the project, selecting Build Path -> Configure Build Path, and switching to the Project tab.
I think the jar file was out of date. I ended up deleting the old one, selecting the project to be referenced, and clicking "Export". At that point, I was able to indicate that all classes and resources in the project should be exported to a jar in the folder I specified.
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.
I have two maven projects imported into Eclipse in the same workspace. Both have a class with the same name and package, but different implementations and in different locations in each project. Let's call this class com.namespace.Factory
Project A has Factory under its test folder, i.e: /src/test/java/com/namespace/Factory.java
Project B has Factory under its main source folder, i.e: /src/main/java/com/namespace/Factory.java
There is also a Project C which is dependent on both. Project C also uses Factory from Project B for some of its unit tests. Problem now is Eclipse can't compile Project C because it can't differentiate between the two Factory classes. If I build all projects in command line, they don't have issues.
You would think that Eclipse would ignore the Project A Factory class since it is in test.
I am using the m2e plugin. My current work around is to setup m2e to not resolve Project C's dependencies within the workspace. This forces it to download the jar that will not have test in it. However, this means I have a change in either A or B, I have to manually install A or B push the latest jar to the local repo, and update Project C's dependencies to pull down the latest jars.
Is there a way to exclude the Project A test folder from the build path in Project C so that I can continue resolving everything within the workspace? It feels like Eclipse is breaking something that is fundamental to maven projects.
I think you're just another user affected by the upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376616
To sum it up, the bug report discussion includes:
JDT implements just one buildpath per Eclipse project. This is very unlikely to change, since this was fundamental design choice and many APIs and implementation details rely on that.
Well, but that doesn't really answer your question I guess.
So I see multiple options here, depending on how much influence you might have on the projects:
either try to rename one of the classes => names would be unique
or if the classes contain basically the same functionality, play with dependencies between projects, or even create new one, that the other 2 would depend upon
that's pretty much what comes to my mind right now
Perhaps you can try this:
In project A's Properties dialog (get there by right clicking the project and then click Properties),
click Deployment Assembly on the left.
Eclipse will show all source folders.
Select the test folder (/test) and click Remove.
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.
What is the "correct"/better place to put eclipse's .launch files in a maven/gradle project? I want to commit my run configurations but I don't know where to put the files
I know maven and gradle are always about standarization so I rather ask than put them in a random folder and then get in trouble with some plugin
After creating a launcher on each maven module now I have each launcher appearing twice in eclipse. This is due to the fact that when I check out my multi-module project it creates an eclipse project for the top POM as well as for each child POM and all the files are "duplicated" in the Navigator view, once for the top and once for each module. This to me means that either I have some problem in my maven organization or that I am putting the launcher in the wrong place
Edit
Since I asked this question I learned of a new way to solve this. Enable an experimental feature in eclipse which will prevent the subprojects to appear in the top project. The setting is under windows/preferences/maven/Hide folders of physically nested modules
The standard location in Eclipse is in the project's root directory, that's where I always save them (and commit to SVN). Maven will ignore them there by default, so they will not show up in your artifacts.
One additional thing to keep in mind (since you mentioned that you want to commit the launch configurations to SCM and possibly share them with others): Avoid absolute paths in the launch configurations, since they will probably not work for other people. Try to use relative paths or Eclipse variables pointing to your local resources.
Edit: moved comment that answers the question
In this case you might consider moving them to a sub-directory (launch?). It should be one that is ignored by Maven by default (so not src/main/java or src/main/resources. On the other hand, I'm not sure whether Eclipse will pick up the files from a sub-directory... I've always kept them in the project root.
I'm going to try to give as much detail as possible here, pardon me if some is irrelevant.
I have two projects in eclipse. Project 1: com.myworkplace.parent, with code in the package of the same name. Project 2: com.myworkplace.child, with code in package of the same name (I moved my code to that package, from the default package, if that makes a difference). Both are located in my workspace folder and structured the way you'd expect them to be, as far as I can tell.
I've added child to the build path of parent in eclipse using Java Build Path -> Projects -> Add. Parent's .classpath file contains the entry:
<classpathentry combineaccessrules="false" kind="src" path="/com.myworkplace.child"/>
I add a reference to a com.myworkplace.child.Child class in parent, import it, compile it with no errors, run and get:
java.lang.NoClassDefFoundError: com/myworkplace/child/Child
What gives?
Edit: The parent application is an RCP app, maybe OSGI (I really don't know much about RCP and related stuff.) Some googling leads me to believe it might have something to do with this.
Since your application is an RCP app there is a difference between the eclipse classpath that is used while you are editing code and the OSGi classpath that is used at runtime. It sounds like you need to add the com.myworkplace.child plugin to the list of dependencies of the com.myworkplace.parent plugin.
Open either plugin.xml or META-INF/manifest.mf in the parent project. Eclipse should open the PDE plugin editor (a form based editor for the underlying config files). Click the Dependencies tab at the bottom and add your child plugin to the "Required Plug-ins" list on the left hand section of the form. Alternately you could add the com.myworkplace.child package to the "Imported Package" list on the right. The difference between the two is beyond the scope of this answer, but you can read about that in the eclipse docs now that you (hopefully) are moving in the right direction.
We found that even doing all the proper things in the eclipse rcp project, we were still getting such errors. The solution was to delete the application's workspace directory (by default it would store workspace settings under .eclipse, but we've tweaked our code to use another dir that is not shared with other eclipse stuff).
When we removed this dir after a rebuild, our app worked. Apparently it was storing the classpath somehow along with other settings, but we didn't investigate the exact details.
(NOTE: This applies only if you've called the IWorkbenchConfigurer.setSaveAndRestore method passing a boolean value of 'true' - which means that your application will save and restore various rcp settings after a shutdown of the application and subsequent relaunch.)
If your code is running in an application server, you need to configure the Classpath correctly for that application server.
To do that, find your Servers tab, double-click it, click Open Launch Configuration in the new tab that appears in the main editing area, click the Classpath tab and ensure the Classpath there is correct.