Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-core-dev] Flexible Project Stucture 
Hi,

Thanks for your reply.
I understand your suggestion, having a folder linked resources with the null file system does prevents a real folder to be automatically created under the project directory in the file system when the project is open.
Although the problem I see then is that it is not a distinct concept at the user level. The user see then the folder as a broken linked resources, he has no way to know that it is actually intended not to exist in the file system. He can still try to create a real file or folder underneath it, and the error will not be handled in a desirable fashion (i.e. with group resources, the user gets notified in the wizard that only linked resources can be created under groups). Also, group resources are displayed with a different folder icon to make it obvious to the user that the semantic is different than a regular folder. The way I see it, allowing "groups" to be a resource level concept (with just being a flag in the resource info of a Folder, really) allow the .project file to be able to fully contain an arbitrarily complex project structure independently of the locations of the files in the file system. With it, we could have Visual C++ and other IDE project files be converted into Eclipse project and all their project structure layout features could be retained. 

Serge.

John Arthorne wrote:
Interesting idea, but I'm wondering why you can't do the same thing without a special kind of resource. Isn't a group the same as a linked IFolder with no physical location? For example, if I created a linked folder in the "null" file system, this folder doesn't appear anywhere on disk, but is still a valid IFolder that can have linked children. Here is a .project file for a project I hacked up that contains a "group" that doesn't exist anywhere on disk, and contains a link to a folder on disk: 

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
        <name>_a_</name>
        <comment></comment>
        <projects>
        </projects>
        <buildSpec>
        </buildSpec>
        <natures>
        </natures>
        <linkedResources>
                <link>
                        <name>group</name>
                        <type>2</type>
                        <locationURI>null://a</locationURI>
                </link>
                <link>
                        <name>group/link</name>
                        <type>2</type>
                        <location>C:/_temp_/location</location>
                </link>
        </linkedResources>
</projectDescription>
This isn't perfect because the "group" has a warning icon due to missing local contents, but one could easily plug in a group file system that simply returns cooked up information for the local file system information. I'm CCing Doug from the CDT project who was also doing exploration in this area. 

John

platform-core-dev-bounces@xxxxxxxxxxx wrote on 02/22/2008 11:27:45 AM:

> Hi everyone,
>
> I work in the Core IDE team at Freescale, and I would like to discuss
> with you on some requirements from our customers that we have addressed
> with changes in the Eclipse core resources plugin.
>
> A very typical way to work with C/C++ project is to reassemble in a
> project sources from different locations in the file system.  Many IDEs
> allow the user to create a flexible project structure where the
> "folders" are virtual only, and can contain files collected from
> different locations in the file system.
>
> Although this is possible in Eclipse by using linked resources, the only 
> way to effectively create an arbitrary complex project structure is by
> having real folders under which linked resources are created.  This has
> the inconvenience of creating a set of empty directories on disk under
> the project folder.
>
> In order to support fully "virtual" projects we have designed and
> implemented "Group Resources".  Group resource is a standard Folder
> resource but that doesn't exist in the local file system (and is
> displayed distinctively to the user). The Group resource is implemented 
> by having a new flag (M_GROUP) and a GroupDescription that is persisted
> in the .project file, containing the path of each group resource.
>
> With mixing group resource (which is seen as a regular IFolder from the
> API perspective) and linked resources, the user can create arbitrarily
> complex project structure without having to create a set of empty
> directories under the project directory.
>
> By design, only linked resources and other groups can be created under a 
> group so we have updated the New File/Folder wizard to give a error
> message to the user may he attempts to perform such task.
>
> Group resources are backward compatible as well.  If the user tries to
> import a project in which he has group resources created in an
> non-group-enabled Eclipse, they will show automatically as regular
> folders (but then folders are actually created under the project
> directory).
>
> Please let me know what you guys think, I'd be very interested to hear
> how our design can fit with your roadmap and whether we could integrate
> our implementation to the standard sources.
>
> Thanks.
>
> Serge.
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
------------------------------------------------------------------------

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev

Back to the top