|
I'm a little puzzled. Why can't encoding's needs be
met with preferences + resource properties?
Bob
----- Original Message -----
Sent: Wednesday, June 18, 2003 10:06
AM
Subject: Re: [platform-core-dev] Re:
pushing the shared metadata idea...
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
|
