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

[Greg_Adams@xxxxxxx]

Based on Rodrigo's email it seems RFC 002 is closed/withdrawn and we are now persueing one of the proposed alternatives , namely a .metadata folder inside the  project.


Comments & Questions
----------------------------------------

*        Seems like it helps cut/copy/paste (drag drop) issue raised by Randy because no longer is the core's meta 
        Randy - is this true?

*        Ensures core is playing more by the same rules.. 

*        (related to above)  However it seems the treatment of markers may still be an issue. As I mentioned in my comments to RFC 002
I suspect there are arguments to be made that the ability to persist some (not all) markers with the project would be useful in a team environment. Jeff the discussion we  had on this seems relevant here.

*        A special export project facility in core is not needed - right?

*        I wonder if someone from one of the web project teams wants to comment - I suspect they have metadata.

*        Do we believe this impacts the current open/close notions in core?

*        Users (advanced) can easily identify which files are project meta data files.

*        Is there any notion of metadata files that need to be presented to a user (during releasing) vs. those that 
        can be ignored?

WRT Rodrigo's Comments
---------------------------------------------
(I hestitate to raise this because I think we should focus on the crux of the new suggestion - but I want to point this as something possibly down the road) 

*        I actually don't agree that markers are a clear example of something a user would not want to be shared. Two possible arguments:
1) If I am archiving a project I would likely want to archive with it the set of current tasks.  
2) In a team environment the team would likely want a way to share tasks.

Possibly we are both right<g> since I would claim  not all markers should necessarily be persisted but there are interesting cases for persisting user defined markers. I would not however push for this to be considered for V2 since the plate is quite full & we need to understand this better in the context of team workflow. 


WRT Jean-Michele's Comments
--------------------------------------------------------
*        Agreed - plugins contributing meta data should also be contributing a comparison. More importantly that comparison should likely not be some text comparison. It should persent the meta information in a manner the user would have typically seen it (e.g. property page). It should also hide anything the user doesn't care about. For example core may have aspects of their meta data they do not want to expose.


WRT Jeff's Comments
----------------------------------------- 
*        Can you elaborate on  "There may be push for additional UI function to open existing projects".
        Do you simply mean, the user knows they had archived their project somewhere on the local
        machines (by copying it) so now they want to say "open" and point at a place on
        disk rather then requesting core open a closed project.

Jean-Michel_Lemieux@xxxxxxx Sent by: platform-core-dev-admin@xxxxxxxxxxx 12/07/01 11:01 AM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-core-dev] RFC 0002 - .metadata under project content area

Ack. Some additional observations in terms of what guidelines could sugggest for all plug-in developers: 

1. A plug-in should persist any VCM shareable project metadata in the $PROJECT/.metadata directory. 

2. A plug-in can use the resource's plugin persistent properties for metadata that is not to be shared with a team. By default the resource's plugin will persist this metadata in a file that will be automatically ignored by the VCM plug-in. 

3. A plug-in can optionally provide compare/merge support for their domain specific metadata. 

4. A plug-in can persist metadata that should not be shared in the $PROJECT/.metadata directory and should register the file as non-VCM shareable. 

Jean-Michel

Jeff_McAffer@xxxxxxx Sent by: platform-core-dev-admin@xxxxxxxxxxx 12/06/01 06:01 PM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx        cc:                Subject:        Re: [platform-core-dev] RFC 0002 - .metadata under project content area

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




_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev