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

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi James,

> Operations made to that tree e.g.:
>  - Moving 'groups' / linked files around the tree doesn't 
> move them in the EFS
>  - Moving Deleting files from tree doesn't delete them from EFS merely
> excludes them from the view.
>  - Adding new linked resources to the tree doesn't affect the
> underlying EFS tree.
> 
> 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?

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
operations that you specify. But what we modify are not
"virtual folders" it's the stuff below the build targets.
Our build system specifies the input into the build targets
by means of (a) references to folders, with addition of
exclude filters by pattern; folder refs can be recursive
including the subfolders or not, and (b) references to files.
The references can be project-relative, workspace-relative
or absolute in the file system (using environment variables).

I'd see the Logical structure that you describe much more in 
a separate View ("Logical Project View") than the Common
Navigator, and much more related to "Resource Perspectives"
shown under a given node like a build target, than fiddling
with the actual IResources we have today.

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).

Please explain what you want to achieve!

Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On 
> Behalf Of James Blackburn
> Sent: Tuesday, October 21, 2008 4:14 PM
> To: E4 developer list
> Subject: Re: [eclipse-incubator-e4-dev] [resources] Resource 
> Folder filters
> 
> On Tue, Oct 21, 2008 at 2:37 PM, Oberhuber, Martin
> <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
> >
> >> i.e. it would be good if users could create a completely 
> virtual tree
> >> of IResources with little overhead if the virtual tree happens to
> >> match the underlying EFS tree.  If they delete resources from a
> >
> > Perhaps I missed something, but what would be "virtual" in this
> > case?
> 
> Operations made to that tree e.g.:
>  - Moving 'groups' / linked files around the tree doesn't 
> move them in the EFS
>  - Moving Deleting files from tree doesn't delete them from EFS merely
> excludes them from the view.
>  - Adding new linked resources to the tree doesn't affect the
> underlying EFS tree.
> 
> 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.
> 
> Cheers,
> 
> James
> 
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>