[
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
|
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
