RE: [cdt-dev] Storing project settings

["Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>]

Hi Wieant,

>We switched off from using the 'persistent properties' mechanism, as
these
>seem to be stored outside of the project, thus tend to get lost when
>exporting the project and are more difficult to incorporate in source
code
>control. Also the hierarchy is getting too complex to catch in basic
>key=value pairs, hence the idea to switch to a special xml file, but
we'll
>investigate your suggestions.
I'm not talking about project persistent properties.
Both project-scoped preferences and build specs are stored under the
project dir.
The project-scoped prefs are stored under the .settings project
sub-directory, while the build specs are stored in the .project file.

Also note that although the project-scoped preferences are presented as
key-value pairs, your string preference value may generally contain xml
data, so you do not have to limit yourself to storing data in the
key-value format.

Mikhail


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Wieant Nielander
Sent: Monday, July 24, 2006 7:42 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Storing project settings


> I agree with your idea in the sense of having one file containing all
> CDT-specific settings. And it is currently proposed to implement this
> for the 4.0, i.e. there could be only one xml file with extendible
> syntax, named e.g. ".cproject" that would hold the CDT-specific
project
> settings.

Ok, indeed mentioned in your new Project Model design document, next
time
i'll check it before...  Currently the referred settings are project
global, but the idea is to allow per-CConfiguration settings, and that
seems to be covered nicely.


> BTW, the current ICDescriptor framework seems to allow extending the
> .cdtproject file syntax and storing custom data in it (see the
> ICDescriptor.get/setProjectData() methods).
>
> As for the .project file, it is maintained by the "workspace
resources"
> framework and holds workspace project general settings.
> The .project file syntax itself is not extendible and we're not going
to
> change this. Note though that the resources framework provides several
> standard mechanisms of storing per-project settings without creating a
> new .xxx file. E.g. via project-scoped preferences or by specifying
the
> build spec arguments, i.e.
> ICommand cmds[] = IProjectDescription.getBuildSpec();
> cmds[i].setArguments(Map);

We switched off from using the 'persistent properties' mechanism, as
these
seem to be stored outside of the project, thus tend to get lost when
exporting the project and are more difficult to incorporate in source
code
control. Also the hierarchy is getting too complex to catch in basic
key=value pairs, hence the idea to switch to a special xml file, but
we'll
investigate your suggestions.

Thanks,
  Wieant
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev