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