Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] [resources] Resource Folder filters
I agree with James that supporting the Project Structure features of VS (and CodeWarrior), which all use the equivalent of linked resources, is critical for our customers.
A simple use case that we have: Import a Visual Studio C/C++ project. It is unavoidable to structure the project with groups and linked resource to reproduce the VS or CodeWarrior structure.
That being said, I think resource filters is a very powerful feature and together with groups and linked resource, they will allow users to create project structure in a way that not only support VS and CodeWarrior's flexibility, but also allow efficient and automatic inclusion of new files and folders with resource filters. 

Serge.

James Blackburn wrote:

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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

Back to the top