Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-core-dev] RFC 0002 - .metadata under project content area

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".


Back to the top