Re: [eclipse-incubator-e4-dev] [resources] Resource Folder filters

["James Blackburn" <jamesblackburn@xxxxxxxxx>]

Hi Martin,

>> The use case is that the user 'imports' a tree virtually into their
>> workspace. They can then rearrange the links into any arrangement that
>> they see fit without affecting the underlying files in the version
>> control.  By virtue of being linked, the IResources are arbitrarily
>> flexible.
>
> Is this a Workflow that your users expect? Why do you
> think that this Workflow is important?

Yes.  The reason it's important is that this is exactly what users
coming from Visual Studio have.  We've got a project moving from VS
with large source repositories in ClearCase.  We're pushing them
towards an Eclipse CDT solution and they (quite reasonably, I think)
don't want to have to move their source to accommodate CDT.

> To me, what you describe sounds arbitrarily confusing.
> So if I press "delete", is the resource deleted or not?
> If I refactor a Java class, is it moved to a different
> package or not?
>
> What you describe seems to be Logical structure of
> a project. It seems to be related to the setup of
> build-targets (libraries, executables) much more than
> the actual project structure.
>
> FYI, in our commercial product (Wind River Workbench),
> we have a Flexible Build System which allows exactly the
> ...
> with the actual IResources we have today.

So for example they're project structure looks like this:

CodecSystem:
  common_headers/
  common_libs/
  common_src/
  src/
    codec1/
       vs_solution/    <vs_specific_context>
       cdt_workspace/   .project, .cproject, build/   (.project
contains many linked resources.)
       src/
    codec2/
        ...
...

So they want to build the full "CodecSystem" as well as individual
standalone codecs under src.
They create a project at the codec level, create linked resources to
source, common_src (yes we know this is bad, but it's what they
do...), headers and libs in the container CodecSystem project.  All
their VS / Eclipse metadata lives in vs_solution / cdt_workspace.
They're source tree isn't polluted in any way.

Effectively they work in a world with a logical view on the project.

Now the WR flexible build system might help us achieve just this, but
the above has advantages:
  - It's open source
  - It works today (!)
        + Serge's patches
        + other small linked resource patches I've submitted against CDT
         (We can edit, build, debug, profile our code using these
projects created entirely of linked resources)
  - Requires no / little additional infrastructure modifications to CDT
  - This logical project model present in the common navigation
framework is exactly what they want to see -- the buid model *is* the
logical model

> Linked Resources seem *not* the right thing to add logical
> structure on top of physical structure. I would really
> recommend that we take a step back and try to understand
> what we really want to achieve with this concept. Editing
> the  http://wiki.eclipse.org/E4/Resources/Requirements
> Wiki should be the result of this discussion, when we have
> some tangible requirements and a use-case (these two being
> orthogonal).

But why not?  In Java it may not suit, but in the C world it's very
desirable -- our competitors provide this functionality.  Serge and I
clearly find this functionality attractive hence Serge's patches
provide just this. The other benefit of "it just works" with today's
platform makes it very attractive indeed.

Turning the question on its head, how (without using WR's commercial
product) would you suggest developers coming in from VS use Eclipse +
CDT? I'm not saying we should have every feature that VS provides, but
flexible resource trees seems highly desirable and there is currently
no alternative...

Cheers,

James