Re: [cdt-dev] Flexible Project Structure - First gotcha with add/exclude

[Serge Beauchamp <serge@xxxxxxxxxxxxx>]

In addition, included to this email are some screenshots that illustrate 
the different UIs implementing our design. (Group resources are in purple).

Thanks.

Serge.

Serge Beauchamp wrote:
> Hi everyone.
>
> I work in the Core IDE team at Freescale, and I was informed that a 
> solution is being discussed to a set of issues that we have worked on 
> addressing on our side.
>
> Basically, we wanted to provide in Eclipsethe same flexibility that 
> our customers had while using our previous IDE.   The requirements to 
> fulfill were the following:
>
> - Create a arbitrary complex project file structure, without being 
> limited by creating files or folders under the project directory. - 
> Easily build up the project structure, without having to go through a 
> set of wizards to build a flexible project structure.
> - Create projects that are portable between computers, i.e. do not 
> depend on absolute paths in its structure definition.
> - Easily view, change and correct linked resources in a project.
> - Create projects that are portable without referring to any specific 
> workspace, and can be imported in a different workspace without 
> loosing any critical information.
>
> The solution that we designed and implemented is the following:
>
> - A new type a IFolder is implemented at the IResource layer, the 
> M_GROUP resource, which is a folder that doesn't exist in the local 
> file system.  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.  The group resources are 
> persisted in the .project file.  Only linked resources and other 
> groups can be created under a group.
>
>  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).
>
> - A new dialog is now visible to the user when he drag and drop files 
> from Windows Explorer or the CDT CView that let him choose whether he 
> would like to copy/move the file/resources over (the current Eclipse 
> behavior) or he would like to create a group/linked resource 
> structure.  In the latter case, the user can select a variable to 
> which the linked resources path will be created relative to.
>
> - The user can now create Path Variables in the project level 
> (previously only available at the workspace level).  The user can then 
> define a set of paths that can be used to specify variable relative 
> path location for linked resources.  Built-in variables includes 
> "PROJECT_LOC", "ENV", "WORKSPACE_LOC" and "ECLIPSE_HOME".  The user 
> can specify macros similar to the CDT macro manager (such as 
> "${ENV-CVSROOT}/ide"), and external plugins can provide additional 
> variables through an extension point.
>
> - The user can now change the linked resources location through the 
> properties info page.
>
> - A tool is now available that allow the user to very easily in one 
> dialog all the linked resources in a project, sorted in 3 section 
> whether they are "broken" (their linked target doesn't exist), their 
> linked location is an absolute path, or "fixed".  The user can then 
> easily correct the broken linked resources, change the project path 
> variables, and automatically convert any number of absolute path 
> resources into variables path resources.
>
> - A lot of fixes have been done to the linked resource implementation 
> to handle properly moving variable relative linked resources between 
> projects with having their variables transfered automatically, etc, 
> etc...
>
> - The project path relative changes are fully forward compatible with 
> other Eclipse distribution, but of course, if a project has linked 
> resources relative to a project variable, they will appear a simply as 
> broken links, the same as if currently the user moves a project 
> between two workspace and doesn't copy the workspace variables over.
>
> Please let me know what you guys think, I'd be very interested to hear 
> how our design can fit with your's and how we can work to make it 
> available to you.
>
> Thanks.
>
> Serge.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev