Re: [platform-core-dev] RFC 0002 - .metadata under project content area

[Jeff_McAffer@xxxxxxx]

I like this as a direction.  The approach solves other problems some people
have had understanding how a project works and how to deal with them.  Some
additional observations/implications:

- Under this model it will no longer be possible for the same project
content to appear in two different workspaces at the same time.  This is a
fringe usecase but worth pointing out.  It is currently possible to run two
workspaces and in each create a project and point it at the same content
area.  To each workspace it would appear as though the resources were being
modified externally.  They would each keep separate metadata (properites,
markers, ...)

- There may be push for additional UI function to "open existing projects".
Currently users who want to treat a chunk of data as a project just
"create" a project and point it at the content.  "projectness" is a
workspace concept so you are always able to find all existig projects (they
are in the workspace!).  Under this new model, projects exist independent
of any given workspace so additional UI function is likely needed.

- If the generic import/export UI function is used, project import would be
a two step process.  Import the project zip and then "open an existing
project".  This can be streamlined by adding an import project which
imports the files form the project zip and then opens the project.  This is
additional UI function.

Overall this is a simplifying approach wihch uses much of the existing
mindset and structure/function.

Jeff



                                                                                                   
                    Rodrigo_Peretti@xxxxxxx                                                        
                    Sent by:                         To:     platform-core-dev@xxxxxxxxxxx         
                    platform-core-dev-admin@e        cc:                                           
                    clipse.org                       Subject:     [platform-core-dev] RFC 0002 -   
                                                     .metadata under project content area          
                                                                                                   
                    12/06/2001 05:07 PM                                                            
                    Please respond to                                                              
                    platform-core-dev                                                              
                                                                                                   
                                                                                                   



Here is a "new" look at solution #2 (metadata under project content area).
Will really like to appreciate from you.

Thanks,
Rodrigo

================================

2.3.1 ( + ) Agreed that Eclipse should have a consistent story on how
plug-ins can identify shareable config info. Here's a first try proposal.
It is a mix of what has already been discussed. We do need feedback from
everyone specially the VCM and UI in order to understand if it meet their
needs.
     Basically, a .metadata folder will exist under the content area of
each project. It will hold all (or most of) the metadata provided by the
resources plug-in plus any other metadata (like the .classpath file)
provided by other plug-ins.
     The interesting point is that some of these metadata will not
(usually) make sense to be shareable via VCM but (usually) makes sense
when a single user wants to move/copy a project from one workspace to
another. Clear examples are markers and persistent properties. The
metadata file that holds the markers cannot be merged. Thus, cannot be
safelly used against a CVS repository by multiple users. Although, a user
that wants to move a project to a new workspace and preserve bookmarks,
tasks and breakpoints, etc... does want to move the markers metadata file.
     What this approach requires from plugins (first cut, need more
feedback):
     * Resources: move all the metadata info to the new .metadata folder
under the project content area. Provide a default state (plug into some
VCM extension point) for each of these metadata files indicating which
ones are appropriate to be shared in a team environment.
     * VCM: It is already there but just to highlight it here. A way for
plug-ins to say what files (or kind of files) should be ignored when
dealing with the repository and make it possible for users to change this
configuration as they need.
     * UI: For the export wizards, the functionality might already be
there. Also, the user should be able to point to a folder (project folder)
or to a file (.prj file) and choose "create existing project from
folder/file".
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev