Ok I'm completely googled-out.
I have a few java projects in my eclipse workspace (about 25). Most projects use linked source folders.
When I rename a class in Project1, the references to that class in the other projects are not updated. The references within the project are updated just fine. The net result is compilation errors on the next automatic recompile.
I'm using Eclipse 3.5.1, but the same behavior was shown by 3.4.0 and 3.4.2
Any ideas about how to fix this?
My current plan - after googling for 20 minutes - is to write a script to convert the linked source folders to be OS links (I'm on linux) in the project folders themselves. So then I'm no longer using linked source folders.
Like Philippe Faes said, it works fine if your projects are set as a dependency on each other. Make sure that your project's build path are set up that way.
IMHO linked folders are for external files, not for another projects.
Another problem is that if you are just referencing a jar as a dependency (ie, on the project's class path), eclipse will not be able to know that the jar was build based on another project's source thus will not refactor properly.
Try to ask your colleagues for the eclipse project files (.project and .classpath) and edit the files if you need, then check if your refactor still doesn't work. I am guessing that your project is set up differently than your colleagues.
Cross-project renames work just fine if your projects depend on each other.
What exactly do you mean with linked source folders: do you link to the same source folder more than once?
This is a shot in the dark, but make sure that your project is a Java project. I am not sure if other project types (like the generic Project) might not refactor properly. I have never seen this problem before and it has always worked as expected for me...
Related
I have a class BaseLoginDialog under a dependency which needs to be modified as it is not extendable out of the box. For this reason, I have created another file BaseLoginDialog under my project's module with the same package path as the original BaseLoginDialog. After adding some new methods in my own local BaseLoginDialog, I cannot use them anywhere in my project without IDEA complaining about the method not being declared. However, the project still compiles and the methods work fine on runtime. If I click the import to browse to the file, IntelliJ still links to the old file but it seems to correctly compile with the new one.
How can I go about fixing this issue? Always having error lines and red markers everywhere makes it confusing when coding.
Some background:
The project uses Gradle for the dependencies and compilation. Compiling and running works both with Gradle and with the IntelliJ run operation, it is only the errors being incorrectly displayed that is an issue.
The Grade file adds the required libraries as dependencies. Even though Gradle has both the source and class files, opening a file imported through Gradle still links to the class files. To get around this I also added the required files as sources under Libraries.
Any help would be appreciated, thanks!
EDIT:
Switched to use a Maven repo on the project, now I don't need to additionally add libraries anymore but this problem still persists.
If two classes of the same name and package exists in the classpath of an application, it's the one that is contained in the first dependency on the command line that gets used.
In IntelliJ, you can reorder dependencies, so you can put your local dependency before the other library. I'm not sure if that works with gradle projects, however.
But I don't think that's a good practice? Why can't you put the extra methods in a subclass, e.g. EnhancedLoginDialog, and use that one?
Or, if the original library is open source, fork it, make the changes and install it as a custom version, e.g. dialogs-1.0-CUSTOM-1.jar, and use this version in your project. And while you're at it, create a pull request for the library's maintainer to include your fixes in the next version :-)
I have resolved the issue.
The file I was copying into my local files was BaseLoginDialog. The file showing errors was my NewLoginDialog which extends LoginDialog which extends BaseLoginDialog. It seems that when IntelliJ goes to my NewLoginDialog, it sees that I have extended LoginDialog. Therefore it jumps into the library files and finds that LoginDialog extends BaseLoginDialog, now when it goes to find BaseLoginDialog, it uses the library files and ignores my local copy of BaseLoginDialog.
Essentially, once IntelliJ branches into a library, it does not move back out when looking for additional files if it can already find it inside the library.
To solve this issue, I simply also copied LoginDialog locally, even though it is identical (simply branched it and did not change anything). Now IntelliJ finds LoginDialog in my local files and as a result also finds BaseLoginDialog locally.
Hope this helps anyone having the same problem in the future.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I've been tasked with picking up someone elses Java code and adding some functionality to it.
I'ved pull down the source tree from CVS and see a bunch of .jar files in different folders. I'm guessing the developer did not use Eclipse.
I am new to Java (coming from .NET background) and have used Eclipse so far to create one Java project. I'm wondering now that I have this guys files (he has classpath.jar and other .jar files along with some subfolders each with 'java' files in them), how do I open them? I tried opening one at a time, etc.. but doesn't seem to work. IS tehre an easy way to do this? I thought there' might be some kind of 'import existing code' thing in Eclipse but I can find it. How can I do this? Do I re-create the folder structure and just add the existing files one a time?
Thanks much for any help
something like 'create project from existing source'?
http://www.stanford.edu/class/cs108/JavaTools/eclipse-guide/
if the existing code is not structured well, you are either going to have to heavily configure your project sources, or just change the project structure.
File -> new
Than select general->folder.
To make developing easier in eclipse i recommend some refactoring to the project.
create a new eclipse project using the parent folder as the home.
every folder that's the root of a hierarchy of java classes becomes a folder in the "source" tab (either on creation, or add through "project->properties").
every jar (at least the ones he's using, there may be extras) gets added in the project->properties libraries tab.
This is assuming that all of the hierarchies belong together and that the thing isn't structured to build little sub-projects out of pieces of the hierarchy. If there's a build file for this thing you might want to be sure that if the build file is doing that you're building things appropriately.
File->Import->General->Existing Projects into Workspace
OR
File->New->Java Project
This will create a sample java project for you. You can add the files appropriately.
Below is an example of a j2ee Project:
http://java.sun.com/blueprints/code/projectconventions.html
If C:\Workspace is the folder you are using as the workspace and you have your existing project placed as "C:\Workspace\ExistingProject"
Open Eclipse Got to File->New Project
Select the type of Project you want to create Use the name as "ExistingProject" for the project and click Finish or complete the remaining steps of project creation wizard normally.
Internally a .project file would be created in the ExistingProject folder and a .metadata folder would be generated under Workspace folder.
If you want to place the ExistingProject not under the workspace u follow the same steps.
There's 2 possibilities:
Import project from file system:
Create a blank Eclipse Project.
Then select File -> Import -> General -> File System. Select project, and point it to your created project.
Importing from CVS
Goto File -> Import -> CVS -> Project from CVS
Enter your CVS Host, Repository Path, Username and Password, and click next,....
Add what you need and click next (follow the instructions) until you're satisfied and click finish.
Hope this helps.
A simple tutorial that incorporates my 1st option and commmits it to CVS: http://thedesignspace.net/MT2archives/000662.html
Two options:
Maven - highly recommended but rather read this: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html than have me re-write it here. Maven might seem like more effort up front but it pays for itself a hundred times over during the course of even a simple project.
Do it yourself (assuming Helios):
Move the source code Java files to ~/development/MyProject/src/java. Move the jars to ~/development/MyProject/resources.
In Eclipse, File > New > Java Project. Type in your project name.
Untick "Use default location" and browse to ~/development/MyProject.
Select src/java as your source folder (if Eclipse doesn't pick it up automatically).
Finish.
Then, for each error, you will need to find the corresponding JAR and add it as a library to your classpath in the project properties.
The important thing to bear in mind is that Eclipse is not like Visual Studio - you cannot easily just edit one file at a time and that is not what it is designed for. People can get frustrated with Eclipse after working with VS but if you just allow it to do things the way it wants you, your life will be much easier.
trick is finding the root folder. Generally, developers use the following:
project root
-- src
-- bin
at least, what's what Eclipse does by default. There are other ways it can be organized as Maven uses the following:
project root
-- src
-- -- main
-- -- -- java
etc...
More info on how Maven standardizes here:
That said, finding out how the source is organized shouldn't be too hard. Open up one of the .java files and look for the line at the top that starts with "package ". Should be something like this:
package com.somecompany.client.utils
Note, that's just an example, it won't be that exactly although it should start with "package". The value after package represents the path that the file should be in relative to the root of the source folder.
source
folder/com/somecompany/client/utils
So, if you follow the default way that Eclipse organizes things, it should look look like this:
project root
-- src
-- -- com
-- -- -- somecompany
-- -- -- -- client
... etc
SO, as other people have mentioned, you'll import from existing filesystem, point to the folder at the project root. You may need to configure it to point to "src" folder as a source folder. You may also need to import those .jar files into your project as well.
Good luck
I usually have multiple copies of a project, for example: a copy of the trunk and another of the last release branch. To cleanly separate my project files from Eclipse, they are checked out from Subversion in a directory outside the Eclipse workspace.
I want to make the project easily importable to Eclipse and followed instructions from multiple answers.
The problem is that my .launch files have the project name hardcoded. When a new project is imported, the launch files will display in the Run Configurations menu just if the project has exactly the same name of the exported one. This forbids me to have two versions of the same project.
It looks like the only way to do it is to have the .launch and .project files generated from an Ant task, but I don't see anyone using this solution. Maybe I should have multiple workspaces and the project always with the same name.
What's the best way to do it?
Edit: I'm marking VonC as the answer, but don't miss the comments.
Remember that the .launch configuration files don't have to be in your workspace.
They can be in your <project>/.settings as I mentioned in the answer you refer to.
That means you cannot import in your eclipse workspace two versions of the same project.
You need separate workspaces (not versioned themselves), each one referring to a project in a different path.
Each path represents different working trees (like different working directories for Subversion).
The OP adds:
The project must have the same name, but the project checkout dir can have any name.
To make the launch file work, you have to reference any file using the variable ${workspace_loc:ProjectName}.
Java files can be referenced using a path like: '/ProjectName/src/package/MyFile.java'
This way, it is easier to use any tool to interact with the subversion repository.
I want to make life easier for who uses Eclipse, but I don't want to force anyone to use it.
My recommendation is to tie the workspace to the checkout location, and then you can use the launch configurations for the relevant projects in Subversion.
My directory structure looks like this:
{checkout root}
|
+code
|
-workspace
In your case, that would mean a workspace for the trunk, and any other branch/tag you check out. I also keep all my projects outside the workspace. The workspace directory in Subversion is empty; I just recursively add the project reference(s) to the workspace from the sibling tree. It also helps if you export your Eclipse settings, as you can then re-import them into each new workspace.
I derived this approach from a pair of IBM and Rational white papers for using Eclipse with Rational ClearCase. This should work unless you need to have multiple versions of the same project open in the same workspace.
I'm porting a few java gwt projects into eclipse and the projects depends on many external .jar files, some of the dependencies seem to be dynamically linked so eclipse isn't picking up the missing links while running the ide.
At run time, I often get exceptions that say for example 'import bar.foo.XML' is missing or some FooBar class definition is missing and it always takes me a while to figure out which .jar file these classes/libraries belong to so I can add them to the run path.
Is there a quick way to search which .jar files contain what classes and what other library they depend on?
An oldie, but still good, and integrated into eclipse:
JarClassFinder:
Update 2013: the project still exists in a different form as an independent app JarClassFinder.
In term of Eclipse plugin, it is no longer maintained, and you only have variant like "BundleclassFinder".
Other (manual) ways to find a class within jars: "Java: How do I know which jar file to use given a class name?"
You need a tool like Jar Analyzer
Can't you just mark all the jar-files in Eclipse and right-click->add to Build Path?