> On 4 Nov 2020, at 17:55, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>
> > From the point of view of the code 'cleanness', I don't like this very much, but given the undesirable effects that changing the IDs have, I'm afraid we have to live with this inconsistency.
>
> We are on the same page :-
I renamed the Java packages; all I need to do is split the .ui from .core plug-ins. The result is published in develop-v6/p2, as before.
However, I noticed a new problem: it looks like trying to maintain compatibility with existing workspaces is not realistic.
For example after upgrading the plug-ins, an existing workspace will no longer find icons:
!MESSAGE Invalid input url:platform:/plugin/ilg.gnumcueclipse.managedbuild.packs/icons/pdficon_small.png
!STACK 0
java.io.IOException: Unable to resolve plug-in "ilg.gnumcueclipse.managedbuild.packs".
The reason is the same workbench.xmi file, where the url is kept.
I don't know if there is any way to refresh this file, but even if there is, it is not realistic to expect the users to know how to do it.
The only safe solution is to create a new workspace and import the projects, which is generally a good strategy when upgrading Eclipse/CDT to a more recent release.
In this case the effort to preserve UI IDs no longer makes sense, and on long term it might be a source of confusion.
So, I would lower the compatibility bar to importing existing projects and launch configurations stored in the projects.
OK - I think that users will accept this limitation based on the move to Eclipse Foundation and related changes. I think you have the right bar for minimum compatibility, it would irritate users if their existing projects stopped working.
We should probably add a sentence in the download page to mention that it is necessary to create a fresh workspace and import the projects.
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