I guess the underlying sentiment is that the Eclipse
project paradigm is fundamentally flawed and we are trying to deliberately
circumvent it. We are trying to address two classes of
user:
1) The Visual Studio user who's used to
picking and choosing what files goes into his project
2) The large project user who has a massive
source tree and only wants a small portion of that tree in his
projects
Build and indexing isn't the whole problem. If it was,
then we have already solved it with Source Folders. I think it goes beyond the
CDT and into things like Team plugins and even the Workspace Refresh. A lot of
plugins assume that everything in the project is interesting and we could
provide customer solutions for each of those to deal with this issue. But I
think it would be much easier if we had a platform solution that everyone
benefits from.
Linked and hidden resources provides such a solution.
Issues users have in the past can be fixed. We need to understand the
workflows and fix them as appropriate. And if that means fixes to the
platform, I do feel we have the attention of the platform team and should be
able to get them addressed.
But that is only my 2 cents CDN. I'm very interested in
what other people think so we don't waste a lot of time on something people
don't need.
Doug.
Hi,
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,
Walter
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).
Cheers,
Doug
Thanks Michael/Szymon,
Is there a bug describing the isHidden
feature?
Doug
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,
Michael