Community
Participate
Working Groups
Bug 472482 paved the way for loading workspace blackboxes from the class files compiled through JDT. But if a blackbox project depends on org.eclipse.m2m.qvt.oml, blackboxes can not be successfully loaded if org.eclipse.m2m.qvt.oml (or one of its dependencies) is itself imported as a workspace project. This is because the qvt.oml project in the workspace includes a new version of the @Module annotation class. Thus blackbox projects are built against this version, so that QVTo fails to read the correct @Module annotation from the blackbox class. Eventually the blackbox load fails because the namespace URIs attached to the @Module annotation can not be read, but they are required to resolve a Java class to the corresponding EClass. The fix is trivial and local: JdtModuleHandle must override the getUsedPackages() method so that dynamic versions of @Module are considered as well.
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193312
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193313
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193402
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193403
(In reply to Christopher Gerking from comment #0) > The fix is trivial and local: JdtModuleHandle must override the > getUsedPackages() method so that dynamic versions of @Module are considered > as well. Pushed to cgerking/579914. Commit ID: c2abe9f07536d1654f26e202f6c01461baec6c57
(In reply to Christopher Gerking from comment #5) > Pushed to cgerking/579914. Commit ID: > c2abe9f07536d1654f26e202f6c01461baec6c57 Wrong, the commit ID is 7e3eca4ffad9988ee852a96b379df57253933b8a.
M3 next week. If you push a cgerking/master I'll 'review' and integrate.
(In reply to Ed Willink from comment #7) > M3 next week. If you push a cgerking/master I'll 'review' and integrate. Thanks. Pushed cgerking/master including fixes for bug 507955, bug 579914, and bug 566236.
Pushed to master for 3.10.7M3. Sorry I cannot offer useful review comments.
Changing from Eclipse 2022.12 to 2023.12 makes the JUnit plugin test for this bug fail with the PDE error "An API baseline has not been set for the current workspace". The "current workspace" is the JUnit runtime workspace. To reproduce bug 579914, the test case ensures that the workspace contains a copy of the org.eclipse.m2m.qvt.oml project, for which API analysis is enabled. The problem goes away when disabling the API analysis for that project by invoking NatureUtils.removeNature(desc, "org.eclipse.pde.api.tools.apiAnalysisNature") during the test setup. But why is it necessary to do this? The error message rather indicates that an API baseline should be set, how would that be possible programmatically during a JUnit test?
(In reply to Ed Willink from comment #9) > Pushed to master for 3.10.7M3. Looks like this bug should have been RESOLVED FIXED. (In reply to Christopher Gerking from comment #10) > Changing from Eclipse 2022.12 to 2023.12 ... Oh joy. Another infrastructure change. But if it was pushed to master for M3, how did the release builds not fail? This is almost certainly a new bug so it should be a new Bugzilla. If nothing else, as a courtesy to the platform team, so that they do not need to wade through the 9 irrelevant initial comments. Superficially, this looks like a perhaps overenthusiastic attempt by the platform team to be more 'helpful'. The problem is who wants/needs the help. If the new functionality is off by default, few users get to see it. If it is on by default legacy usage may be broken. Some analysis may be needed to see whether the extra help should be available, or whether some 'guard' has been overlooked. Behind the scenes I think this test autogenerates a new project and so it may be an autogenerator test code bug that the 'use API baseline' preference has not defaulted appropriately; a trivial fix that you have perhaps already found. A little analysis is needed to decide whether this is a QVTo or platform bug.
(In reply to Ed Willink from comment #11) > Looks like this bug should have been RESOLVED FIXED. Right. Done. > This is almost certainly a new bug so it should be a new Bugzilla. Externalized to bug 582831.
