Community
Participate
Working Groups
It looks like some of our project metadata was accidentally changed in our plugin/package renaming efforts in the Indigo release. The following discrepancies have been identified: org.eclipse.jpt.jpa.core.discoverAnnotatedClasses org.eclipse.jpt.jpa.core.metamodelSourceFolderName which should have stayed as: org.eclipse.jpt.core.discoverAnnotatedClasses org.eclipse.jpt.core.metamodelSourceFolderName We will need to ensure that the old setting remain compatible with newer versions.
At this point do you think I should go with the new String as the correct one? Potentially there are people who have not upgraded so they would only have the jpt.core preference. I assume they would only end up with the new jpt.jpa.core preference if they actually changed the preference. I think this is what you were suggesting as well, read both, write the new jpt.jpa.core preferences. I will also clear both in the JptJpaCorePlugin.clearProjectPreferences
Created attachment 202093 [details] proposed patch against 3.0 maintenance
(In reply to comment #1) > At this point do you think I should go with the new String as the correct one? The fact that this was an unintentional change, and therefore an incomplete evolution (other settings still being jpt.*) it feels like the least awkward solution is to revert back to our previous metadata to retain forward compatibility from 3.0.1 and up. The 3.0.0 metadata will of course be supported moving forward, but the original 2.x metadata will be written. As a result, 3.0.0 will be the only non-forward compatible version. That said, I do think it is reasonable for metadata to evolve in a planned, orderly fashion. I don't think forward compatibility should ever be guaranteed for all possible releases. This particular bug has demonstrated our lack of unit tests for our project metadata. As a result I have entered bug 355720.
Created attachment 202098 [details] proposed patch against 3.0 maintenance
On second thought, the down side of reverting back to the original metadata is that we once again break future compatibility from 3.0.0 to 3.0.1. It is also impossible to know in the future what the newest metadata is, since the original metadata could be old or new. As a result, you could set something in 2.3.x, change the setting in 3.0.0, and then in 3.0.1 we don't know what the latest setting is as both new and old metadata would be present. Given this, I think the first solution, to move forward with the new metadata is actually the least disruptive path forward. It prevents us from having forward compatibility issues in the same major release version, which is more important. Special consideration is also needed for the metamodel generation metadata, as when this is turned off, the preference is simply removed. As a result, when this option is disable, we will need to make sure we remove all metamodel generation metadata from the preferences.
Created attachment 202116 [details] patch v3 This patch goes back to the first patch code and adds removal of metamodel generation metadata when necessary.
Patch committed to maintenance and head.
