Community
Participate
Working Groups
Eclipse's project assumes that a project contains all the files in a directory and its subdirectories. While this is consistent with some IDEs, it is not consistent with others, where a project is a collection of files and directories which are not necessariliy in the same common directory. (For example take JBuilder). As the second approach is more general than the first, it makes more sense for a framework that allows to create IDEs. Note that even when all the files of a project are in the same directory, there are still good reasons for distinguishing the content of the project from the content of the directory. For example, the user may want to remove some files from a project without deleting them from the project directory. As far as I can tell, this common operation is not supported today. I propose to extend IProject to add an API that allows to explicitly indicate which files belong to the project. For backward compatibility, old project should still be treated so that the entire directory belongs to the project. Also, a flag at creation time for the project could indicate which mode to use (and the default should be the old case).
Do you know about the whole 'flexible project structure' concept implemented in Eclipse 2.1? I mean top level linked files and folders; see http://www.eclipse.org/eclipse/development/flexible-projects-proposal.html . This lets you gather files and folders from all over the place into one project. What's missing?
No, I wasn't aware of this, and it seem to partially address my problem. This mechanism is not mentioned in "The Java Developer's Guide to Eclipse". I looked into IProject to find an API to add/remove files, hoping that this was added in 3.0, but didn't see any. Now I see from the link you sent me that things are done at the IFile level. Thanks for the tip. I noticed though that the problem of excluding files is not addressed, and that's a shame. Also, the support for linked files only at the root level is restrictive. An approach where a project is a container, it can contain additional containers or files, and containers may be directories or just logical containers of elements spread on the file system would have been cleaner... but I guess it's to late to change this, isn't it?
The JDGTE book was based on 2.0 and flexible projects was a (if not *the*) major new 2.1 feature. The authors are working on a revised edition for 3.0 but meanwhile the Javadoc is the ultimate reference. Like you say, it's not totally flexible like nested symbolic links, but there are reasons (explained in the proposal or accompanying documents I believe) that they didn't go whole-hog. I remember this got a *lot* of discussion at the time, which is probably still in the archives. In addition to this feature, you can include and exclude source file patterns through the project Properties > Java Build Path > Source. I believe that's a new feature in 3.0. Hopefully these two things, linking and include/exclude source filters, will let you do what you want and you can close this out. Give it a try for a while and if it doesn't work for you, I suggest opening a different entry with a specific use-case of what you need to do and why it's not working. Those platform-core guys love their use-cases. :)
Thanks, Ed. *** This bug has been marked as a duplicate of 6664 ***
