Re: [platform-core-dev] Re: pushing the shared metadata idea...

["Rafael Chaves" <Rafael_Chaves@xxxxxxxxxx>]

No, so far it was a "single-message
thread". I have been told that there had been a discussion about this
before, but I didn't know it was in the list archive (thanks for pointing
it out). It was also a good idea to move it to platform-core-dev because,
as you said, it is related to the new proposal for shareable preferences
(although this message was written before the proposal was made available,
and the proposal authors never read this before).

Rafael

John Arthorne/Ottawa/IBM@IBMCA Sent by: platform-core-dev-admin@xxxxxxxxxxx 18/06/2003 10:51 AM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-core-dev] Re: pushing the shared metadata idea...

Hi Rafael, I don't know if you've had discussions about this while I was
away, I may have missed it since I went through my mail quite quickly.
 First I wanted to point you to the thread from our last discussion
about this idea: 

http://dev.eclipse.org/mhonarc/lists/platform-core-dev/msg00048.html

My only real concern about moving the .project file again is the backwards
compatibility nightmare.  We currently have to look for a .prj file
(which used to exist before .project), and team looks for a .vcm_meta file
(the old name for the shared project description file).  It's also
confusing for users because they don't know what's safe to delete and what
needs to be shared.  Another option is to just add the file encoding
information in the .project file.  This was the approach used for
linked resources.  Since it's XML it's fairly easy to add more elements
in a backwards and forwards compatible manner.  This would avoid creating
more files/folders that clutter the user's content area and doesn't introduce
any new concepts from the user's point of view. 

I've moved the discussion to the mailing list so we have a record of it
and so other interested parties can follow it.  I suspect this is
something that will also need to be discussed in the context of the shared
user preferences work. 

John 


> Rafael Chaves wrote: 

Now that I am working on the file encoding stuff, I think that that idea
of having shareable project metadata inside the project's content area
(preferrably inside a common special root) can be really interesting (because
I will probably need to add another metadata file to the project content
area). 

Looking for cases where plug-ins do/could store metadata in the project
content area, I found these:

• Project relationship to natures and builders - shareable - .project XML file in the project root directory.
• CVS - metadata is not shareable (neither would make sense), uses CVS directory structure (to be compatible with external CVS tools) and plug-in's state location.
• External tool builders - shareable, stored in the project description file.
• Launch configurations - can be optionally shared - if so, instead of using plug-in state location, a corresponding "proprietary" XML file (<config-name>.launch) in the content area of a arbitrarily selected project (maybe because some types of launch configurations, such as "Run-time Workbench", are not related to a specific project).
• Java compiler options and Java task tags - not shareable properties file (might be interesting to share) - if the user selects to have project-specific configurations, they are stored under the project specific plug-in's state location (under core.resources metadata area).
• Java build path and project references - shareable - .classpath XML file in the project root directory.

We could have a new API IProject.getPluginShareableLocation (or something
else) which plug-ins would call (instead of IProject.getPluginWorkLocation)
to have a location inside the project contents area that would be easily
shareable. This location could be a .shared.metadata directory (or something
else) inside the project root directory, where:

•  the resources plug-in would store the project description file;
• JDT would store the .classpath file;
• JDT could store the project-specific compiler options preferences (if the user wants so);
• the external tools plug-in would store shared launch configurations (if the user wants so).

This way, we would provide an uniform way for plug-ins that want to allow
users to share project-specific configurations/properties.

Of course, the number and size of shared metadata files should be small,
and the file contents shoud be easily readable (to make comparisons possible).

Any thoughts? 

Rafael