> *
Warren.Paul@xxxxxxxxx
> *Sent:* Friday, January 25, 2008 11:22 AM
> *To:*
cdt-dev@xxxxxxxxxxx
> *Subject:* RE: [cdt-dev] First gotcha with add/exclude
> children of FFS
>
>
>
> We've been working on Eclipse/CDT based products for about
> three years now. I'm sorry to say that the project model is
> still not satisfactory for our purposes. We've tried many
> angles, but are still stuck with some pretty serious
> limitations. I've volunteered to investigate the EFS route to
> see if it will help at all. Based on this thread I'm assuming
> it won't.
>
>
>
> Let me give you a brief overview of how our users work, and
> then discuss the problem we've run into. I don't think any of
> this is specific to our users BTW.
>
>
>
> Most of our users have existing code bases. They simply want
> to "import" it into the IDE. Others will create new projects
> from our templates. The new projects are created in the
> workspace. Imported projects could be anywhere in the file
> system. Often times they will import several projects from the
> same source tree. This is where our biggest problem is. Let's
> say the source base looks like this:
>
>
>
> C:\MyProjects\Project1\...
>
>
> C:\MyProjects\Project2\...
>
>
> C:\MyProjects\Common\...
>
>
>
> Because both projects share code in the Common directory, the
> logical root project directory for both Project1 and Project 2
> is C:\MyProjects\. But in Eclipse you can't have two projects
> with the same root. This is where the .project and .cproject
> files are created. So currently our users would import
> Project1 with the natural root (C:\MyProjects\), but Project2
> has to be rooted at C:\MyProjects\Project2\. This means that
> any source/headers from the common directory are not under
> Project2. This means those files are not in the project
> explorer for that project, are not indexed, etc.. We logged
> this against the platform -
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=78438. Basically
> if you put the .project file anywhere, but have a project root
> attribute, this would cease to be a problem.
>
>
>
> Our first product actually always created the .project in the
> workspace, and for imported projects, would create links to
> files and folders. We ran into so many issues with this that
> we had to change the model. I don't recall all of the issues,
> but here's a list of some:
>
>
>
> - Version control simply didn't work at all
>
>
>
> - You can't make file system changes with links. For example,
> if you want to rename a file or folder, or move a file around,
> you can't do this with linked resources. It only changes the
> link itself, not the underlying resource.
>
>
>
> - Creating new resources in a project with links is confusing
> at best. Let's say you have a project with a linked folder and
> file at the root. If you create a new file or folder at the
> root, it is created in the workspace, not where the other
> folder/file are in the file system. But if you create a new
> file under the linked folder, it gets created where you'd expect.
>
>
>
> - The location of the .project/.cproject files are
> problematic. Some users will want to keep these in version
> control, while others won't. Those that do want them created
> in the source tree, but those that don't want them elsewhere,
> like the workspace. I forget now why this was a problem with
> linked resources, but there was something weird going on there.
>
>
>
> I suppose it's worth noting that the last time we really
> looked at this was in Eclipse 3.2, so some of this may have
> been fixed by now. But I doubt it. In general linked resources
> are second class citizens. Some IResource API's just don't
> work for linked resources. Just search for references to
> IResource#isLinked for "special handling". I suspect that
> we'll run into similar issues with EFS though - see
> getLocation vs getLocationURI.
>
>
>
> We also have the same issue that Doug is trying to address
> (hiding some branches in a source tree). This is much less of
> an issue for us though. You can already reduce the scope of
> the indexer and the build. The only real issue for us is for a
> very large source tree, you're going to get IResource's for
> everything, which slows things down quite a bit. There is
> actually somewhat of a problem in reducing the indexer scope -
> see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178159.
>
>
>
> The hidden attribute addition sounds promising for hiding
> resources under the project root, but doesn't really do
> anything to add flexibility to the contents of a project. EFS
> sounds like it would though. What I mean by that is, having
> resources under a project that are real resources, not linked,
> but that don't live under the project root in the file system.
> I've just started looking into EFS, so maybe it's a bit of
> wishful thinking at this point, but I'm hoping we could create
> a project anywhere, and when we create it we pass the URI
> location from our own EFS. Then when asked for the children,
> we could return URI's for files from anywhere in the file
> system, or on other machines even. This would seem to hold the
> potential for working around the issues listed above. We'd
> basically have an EFS map from what we want under a project to
> the actual file system.
>
>
>
> So hopefully some of the experts can chime in here. Is my hope
> for EFS unrealistic? Is there a different approach we should
> look at?
>
>
>
> Thanks,
> Warren
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:*
cdt-dev-bounces@xxxxxxxxxxx
> [mailto:
cdt-dev-bounces@xxxxxxxxxxx]