Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects

[Rodrigo_Peretti@xxxxxxx]

See <RP>.
----------------





"Jean-Michel Lemieux/OTT/OTI" <Jean-Michel_Lemieux@xxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx
12/05/2001 10:08 AM
Please respond to platform-core-dev

 
        To:     platform-core-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects


I'm a bit late in the discussion <g> 

>In summary it is unclear to me why core would want to get into creating a 
projectExportFile. It >seems to be just a zip that includes some metadata. 
>Why doesn't core simply add api to produce/read this metadata 
description? A file with this >metadata could be added to the project/read 
from the project, on export/import with only minor >modifications to 
existing File System and Zip wizards. 

The VCM plugin exports/imports projects, but not into a zip/jar but into a 
repository. There is one main undocumented requirement that VCM has 
imposed on plugins that want do be VCM import/export compatible: a plugin 
_must_ save shared configuration information about a project into the 
project's file hierarchy and not in .metadata (e.g. .classpath is managed 
by JDT). However, the resources plugin does not play by the same rules. 
The VCM plugin was made responsible for persisting the shared 
configuration information for the resources plugin (e.g. .vcm_meta). 

My questions: 

1. Why should the resources plugin be special in regards to VCM 
import/export requirements? 

<RP>
I agree that it should not. But it is easy to look at the current scenario 
and say so. Currently, the only resources information (that I know) VCM is 
sharing in the project content area is the project description. This 
information can be easily represented in one file and changes to this file 
do not need to be merged.

Now, thinking about the future and getting something more complex like 
markers (or persistent properties). As an implementation detail, they are 
currently persisted as one unique file. If we keep this format, this file 
would need to be merged if it gets out of sync with the repository. To do 
so, more APIs will have to be added in order to VCM inspect it and figure 
out what has changed and ask the user what should be done (as it currently 
does with text files). I'm not saying it is impossible, only that it is a 
kind of change that will likely be hard to happen.
</RP>

2. How will the resources plugin document the requirement that for plugins 
to be import/export compatible they must save their shareable project 
config info into the file system and not in .metadata? 

<RP>
It would be: "For plugins to be import/export compatible they must save 
their shareable project config info into the file system." ;-)
</RP>

The resources plugin is not the only plugin interested in importing and 
exporting projects. Eclipse just don't have a consistent story for how 
plugins can identify shareable configuration information. The suggested 
API is, in my opinion, another way of avoiding the issue of how to handle 
the problem in a more general way. So how can the general import/export 
mechanism support both VCM's and a zip/jar tool needs? 

<RP>
Agreed that the platform as a whole does not have a consistent story about 
shareable configuration info. If the API proposed is not enough, all the 
interested parties should try to come up with something else and we put 
the current proposal on hold. I'm not moving on this proposal to voting 
since it does not seem to be solving people's expectations. Will annotate 
the proposal with all the significant comments and move its status to 
"early draft".
</RP>