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

[Serge Beauchamp <serge@xxxxxxxxxxxxx>]

Hello again,

I'd like to add a comment regarding team support and linked resources. 

The way I see it, one of the major reason why customers want to have 
flexible project structure is because a projects needs to build with 
files located in different locations in a source control repository.

So if the user didn't have sources in a source control repository, it 
wouldn't be that hard to simply move the files under the project 
directory, as long as he doesn't need to share sources between projects.

So the usage of a source control repository is a major factor that 
drives the user's requirement to have flexible project structure, so 
there's little point of having team support working without flexible 
project structure.

While the opposite is not necessarily true, I would guess that very few 
customers are actually dependent on the Eclipse implementation of the 
source control clients, since the user has typically native clients to 
rely on. 

That being said, if team support doesn't support linked resources, 
independently of flexible project structure, that seems to me to be a 
bug that needs to be fixed, instead of driving the design of the 
flexible project structure.

Thanks.

Serge.

Serge Beauchamp wrote:
> 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
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>