[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] First gotcha with add/exclude children of FFS

after reading this rather long thread, I'll decided to throw in my personal opinion.
I consider this approach to work against one of the most general Eclipse platform paradigms, where a project is defined to be a root directory and everything in it. IMO, the more workarounds are introduced against this paradigm, the more problems will be faced, and the more incompatibilities (or at least unawarenesses) created.
Isn't the whole problem you try to solve here rather about what files should go into the build (and probably into the indexer) than what files are part of a project? I understand that CDT has no separation of what a project and what the build input is (well, IIRC one can exclude specific files from the build, but in general, the project content defines the build input, right?).
In our commercial IDE, we separated this. This not only introduced much more powerful build setup capabilities in general, but especially enabled users to setup build artifacts with arbitrary contents (think of sources being compilable with different compiler flags for different build artifacts, build input exclusion patterns, build input from all over the workspace, multiple build artifacts within the same project, reusable build artifacts accross project boundaries, etc., etc., etc.). BTW, we call this build system flexible managed build - because that's what it is:-)
Of course, one can setup CDT projects as of today to exactly contain what is desired (with the help of linked resources). However, I find linked resources to be cumbersome and error prone, though many of our customers start out with them during evaluation as well, mostly because they are looking for a way to achieve what they did in the past with other non-Eclipse based IDEs, but sooner or later I know of lots of them realizing its much easier to use the features of our flexible build system instead, especially if projects need to be shared in a team. And now think of virtual file systems, the potential complexity of these, hidden assumptions, restrictions, etc. Sounds worse than linked resources to me.
I guess, the point I am trying to make is: whatever you decide to do, make it understandable and transparent (and of course as simple as possible to use) for the user.
As said, just my 2 cents,

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Donnerstag, 24. Jänner 2008 23:17
To: CDT General developers list.
Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS

Jogging through the code, it really looks like the HIDDEN feature is what I was looking for. What I haven't found yet is UI to make a resource hidden or a navigator filter to show hidden resources (in case you want to bring them back). Is this planned?
Assuming we have the core features available to link in and hide resource, I think we still have workflow issues that need to be addressed. I like Ken's idea of a file that controls the linking/hiding. We could have an import/export mechanism for setting up projects based on this file. A nice wizard for creating the file would also be good, similar to the way the way the export file system wizard works.
Given this, we may be further along than we thought (BTW, the hidden stuff seems to have been added in 3.4 M4).

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Thursday, January 24, 2008 2:51 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS

Thanks Michael/Szymon,
Is there a bug describing the isHidden feature?


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Valenta
Sent: Thursday, January 24, 2008 11:37 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS

Doug et al,

Szymon is really the person you want to bug on this but I'll throw in my 2 cents ;-)  First, I have to say that a solution at the IResource level (e.g. using linked resources and the new hidden folder support) is infinitely better from a repository provider perspective than an EFS based solution.  You may not get all the Team support you want at the IResource level but a solution at the EFS level would certainly break the existing CVS client since the CVS client isn't EFS aware to any great extent. For instance, if you tried to hide a folder using EFS, the CVS client would probably try and recreate it the next time you performed a Team>Update. It is also important to note that the Platform does not provide all the hooks required by repository providers and I know of at least one provider that has resorted to using it's own EFS implementation under projects that are mapped to that provider to get the capabilities it requires. I think it is important that tooling in Eclipse stick to using the IResource layer as the layer they operate on and let the repository provider (or any other tooling whose responsibility it is to manage the available files) control the underlying file system. If there are shortcomings or enhancements required then you should push to get them in at the IResource level.

As for the current state of Team support for linked resources, I think the best approach is to enumerate some specific scenarios of how you see linked resources and exclusions working with descriptions of what you need to do today to get Team support and what you would like to see. It is also important to know if you expect all the links to come from the same repository (or at least repository type) or whether a project could contain content from different repository types (obviously the later would be more difficult to accommodate than the former).

Hope this helps,