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

["Spam-Receiver" <spam-receiver@xxxxxx>]

Dear all,

I am not a CDT developer, but only mailing list reader. So I don't know
about Eclipse internals.

But there is a point I want to emphasize:
To me it is important, that the "Team" plugins (in my case ClearCase) work
correctly. 
Mr. Schaefer mentioned, that there are problems concerning linked
ressources, and I observe the same.
So please keep this point in mind when you design a change.

Thank you,
spam-receiver


-----Ursprüngliche Nachricht-----
Von: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Serge Beauchamp
Gesendet: Donnerstag, 21. Februar 2008 23:14
An: cdt-dev@xxxxxxxxxxx
Betreff: [cdt-dev] Flexible Project Structure - First gotcha with
add/exclude children of FFS

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