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:
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).