[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [embed-cdt-dev] Rename bundles and packages - no compatibility for third parties
|
All the UI identifiers are stored under
${workspace_loc}/.metadata/org.eclipse.e4.workbench/workbench.xmi
In theory, the smooth migration can be provided with E4 Model Processors
but I consider this as not the first priority.
For preference store I would consider to migrate all the preferences
once during startup using AbstractPreferenceInitializer
For .launch files and project data we can also suggest a migration, but
this could be much more tricky.
Perhaps we can have both "old" and "new" contributions for some time,
with marking "old" as "Deprecated " in UI, this will give us more room
to implement and test the migration.
WDYT?
Regards,
AF
04.11.2020 11:08, Liviu Ionescu пишет:
On 4 Nov 2020, at 08:16, Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> wrote:
My vote is to proceed with the "rename" changes and declare the major release. The moment seems very logical as we are joining SimRel and after that the change of this scope will be much more painful.
I'm working on it, but for the moment I don't know if I'll be ready on time.
As one of the integrators I do not consider the namespace change as a need to "rewrite". The change like this may be applied more or less "mechanically" with global search/replace.
Ok.
From this point I would like to understand what we are going to keep in the "old" namespace and find the acceptable solution for each item.
My initial approach was to update all IDs, except those in .cproject.
Then I discovered that I also have to preserve the IDs in the debug launchers, which I did.
When I updated the codered perspective, I noticed that the perspective did not display the views, complaining about missing old IDs; I don't know the perspective details, I guess that some IDs are somehow persistent, probably in the workspace, and cannot be changed.
I also discovered that the UI plug-ins use a lot of IDs as view names, commands, etc, which I don't know if they are stored somewhere in the workspace or not.
There are also the variables stored in the preferences stores, which are usually tied to a plug-in. For them I implemented a logic to try to get the value from the new org.eclipse namespace, and, if not there, retry with a plug-in ID where 'org.eclipse.embedcdt.' is replaced by 'ilg.gnumcuelcipse.'. This should be fine as long as the plug-ins are not reorganised and split into multiple plug-ins.
Late in the night I renamed the managed build plug-ins, and the first result was that the setting pages no longer showed, so I expect some issues there too.
The conclusion is that a lot of internal IDs might need to be preserved. I'll know more after fixing the managed build plug-ins, but for now I'm not very happy with the result; preserving compatibility for users seems more tricky than we expected.
Regards,
Liviu
_______________________________________________
embed-cdt-dev mailing list
embed-cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/embed-cdt-dev
