Community
Participate
Working Groups
It appears that regardless of whether you use classpath variables or linked resources, the build path will not recognize external class folders. I have several projects, each sharing various common base projects. In the past (<= 2.1) I always had to have all relevant projects open in order for the build path to be properly computed. Since upgrading to M6, I have found that the restrictions on linking to resources either via classpath variables or by external linked resources (i.e. mounting a folder via linked resource) have been eased. In other words, the linking process no longer cares whether the resources are in another project, however, the build path still does not recognize the resources when the resource is a class folder. Here's how to reproduce this. 1. create a project (say c:\project1\) 2. create a second project that is dependent on the resources in the output folder of the first project (i.e. as a class folder, like c:\project1 \classes), only don't open the other project. Your choices in setting up the dependency are a. to use a variable linked to the output folder - in the build properties of project2, select, "Add Variable", and select the (previously defined) variable that points to the class folder (in this case c:\project1 \classes) b. mount a class folder - this is done by defining a class folder linked to the file system. The folder can be linked to the file system either through a variable, or by explicitly defining the path. The essence of this bug is that despite being able to define the build dependencies in a variety of ways, if the dependency is to a class folder, the build path does not pick it up.
But you did close the project containing the class folder, didn't you ?
Please reopen once requested information is made available
To answer your question, yes, the source (as opposed to the dependent) project is closed. The interoperability problem boils down to the following. 1. classpath variables bound to class folders are not resolved at build time 2. class folders linked to external resources are not resolved at build time I am not sure whether this has anything to do with the fact that the class folder I am trying to link into the build process also happens to be the output folder of another Eclipse project. In prior versions (<= 2.2?), this used to be checked and prevented.
I've done further investigation of this issue, this time using M7. I have found the following. You cannot use Classpath Variables to link in external class folders. I really don't understand why not, as it would actually be far simpler to do this. It appears that M7 fixes the problem of linking in the external class folder when the class folder is defined as a linked resource. However, this only works when the external link is an explicit one to the a location in the file system, not when the link is made to a classpath variable that points to the same location. The end result is that I have a project with hard-coded links to class folders, but libraries that I've linked in using classpath variables. I'd like to remove the explicit, hard-coded dependency altogether, and rely solely on resources linked in via classpath variables.
Linking to internal of closed projects is likely your problem. Try to open the target project, and things should work fine. Also, why are you adding explicitly the output folder of first project to the classpath of dependent project ? Why not simply adding a project reference from one to the other ? It is taking care of offering the output folders for free, and ensure the build order is correctly tuned (i.e. some project needs to be built before the other).
So it comes to this, why do I want to be able to link projects regardless of whether or not they are open? The simple answer is this, to make Eclipse a usable tool. As it is, it's memory usage with all projects open typically stays around 180-220MB. The projects are both large and dependent on many 3rd party libraries. Secondly, the default java builder (which I really want to be able to disable in favor of my own custom Ant build) takes forever to figure out the build dependencies with all these open projects (typically 5-7). Most other IDEs allow you to setup any one project's classpath independently of others'. I don't understand why it should matter whether a class output folder is generated/populated via a project or not. If it's a class folder, a user should be able to put it in his classpath and use it.
Eclipse organizes resources in projects. If you close one, all its resources are no longer accessible. Thus dependent projects won't see them at all. Alternatively, you could mount filesystem directories using linked folders, or jarify some binary folders and use them as libraries. If you have a performance problem with 5-7 projects, then something is likely wrong, and you should enter defects about this. I develop Eclipse with a workspace containing 80 projects, and it runs fine. I will close this defect as invalid, since this isn't a valid setup. But I recommend you provide input on performance issues with reproduceable steps, and we will look into these.
