Community
Participate
Working Groups
Follow up from bug 240914, I found that added restrictions appear as errors in the MANIFEST file rather than on the types themselves. When a restriction has changed, I would expect the error to appear on the changed member. For example: Description Resource Path Location Type Restrictions have been added for type org.eclipse.compare.patch.IFilePatchResult MANIFEST.MF org.eclipse.compare/META-INF line 27 Compatibility Problem Restrictions have been added for type org.eclipse.compare.patch.IHunk MANIFEST.MF org.eclipse.compare/META-INF line 30 Compatibility Problem Restrictions have been added for type org.eclipse.compare.patch.PatchConfiguration MANIFEST.MF org.eclipse.compare/META-INF line 24 Compatibility Problem
The problem comes from the fact that we are reporting markers against the project that we are checking. In this case the type has been moved to a new bundle in the workspace baseline. So we detect the restriction change when analyzing org.eclipse.compare, not org.eclipse.compare.core. It is unclear if org.eclipse.compare.core is also from source in the workspace. We could have org.eclipse.compare from source and org.eclipse.compare.core from binary. In this case there is no better place to report the marker than the MANIFEST.MF file of the current bundle (i.e. org.eclipse.compare). If org.eclipse.compare.core is from source, we could try to locate the error on the corresponding type. Any thoughts?
Sounds like we should maintain the workspace relative path in order to create problems properly (rather than project relative, since we can analyze types outside the project). We need to investigate if "baseline-relative paths" work in the case for non-workspace (releng build) analysis. Ideally, the problem would reside with the type/project where the problem resides. In the workspace we should only create the problem marker if the corresponding project exists. In the releng analysis, we create the problem against the corresponding component.
Note that this bugs gives a strange/confusing result when opening the manifest (see attached image).
Created attachment 121792 [details] Image of editor with red squiggles at wrong places
I am investigating this issue trying not to break existing filters.
When I investigated this issue, I discovered some new ones. When we have a bundle that is split into two different bundles in the current stream, we have multiple issues. Let's say we have: A -> A' + B (re-exported through A') If I compare A and A', I can find out that some types (in A) that have been moved to B have new restrictions. This is exactly the case that we have with compare and compare.core. Right now the logic is to compare bundle to bundle. So when comparing A to A', no problem. We detect the right errors and we can report them on types in B if necessary. However this leads to new issues like: - where do you put the filters for these errors? Filters should be reported against the corresponding project since they can be per project. So we should record the filters for these problems in B even if we are comparing A and A'. This means we have to be able to retrieve the right api store in order to find out whether a problem is filtered or not. Now the last issue I found. Incremental build of types in B or full build of B removes the problems against the types from B since B has no equivalent bundle in the reference baseline. I could not come up a good solution so far to be able to retrieve the types from A when rebuilding B. B is a bundle on its own. So we should be able to rebuild it with a full build or an incremental build and still be able to "preserve" the errors detected when building A. If you have any idea how this could be handled in a way that is not confusing for the users, please let me know. I can fix where the errors are reported, but this doesn't solve all issues with this split bundle case.
So reporting the errors on the right types is not an issue, but incremental and full build of the new bundle (not present in the reference baseline) is the remaining issue.
After more thinking about this, I plan to do the following: 1) report restrictions errors against the compare bundle. From an API standpoint, changing the restrictions of some types that have been moved to the new compare.core bundle only affect users of the compare bundle. Users of the new bundle are not affected as they will use the types directly with the modified restrictions. So it doesn't make sense to report the error against the types defined inside the compare.core bundle. 2) This being said, I think we should report the errors against the project. I don't see a good reason to report these errors against the MANIFEST.MF file. This will require changes in the way the api filters work. Right now it is not possible to add a filter for markers reported against the project. We should get rid of this limitation. Now we still have an incremental build issue. When removing the added restriction on types inside compare.core, the markers on the compare project should be removed. Same apply when adding more restrictions or making more changes to the types defined inside compare.core. Any thought on this ?
I think logically the project is the right place but the advantage of putting it on the manifest is better support for quick fix and eventually you can give more context in the quick fix hover.
So you are suggesting that I should simply report the markers on the first line of the manifest ? I discussed with Darin a way to get the incremental build working in this case. I'll try to get it done today. The full build issue is not a problem because all markers are cleanup up. The incremental build is more tricky in this case. This would be true for all types moved to a different bundle even if the target bundle exists in the reference baseline. The major issue is that I cannot report these errors on the compare.core bundle in this case as users of the compare.core are not concerned with changes made the compare bundle. Restriction changes are only an issue in the context of the compare bundle, not compare.core.
>So you are suggesting that I should simply report the markers on the first line >of the manifest ? Yes.
Released for 3.5M6. Darin, please verify.
Reopen. This is causing lots of side-effects. Needs more investigation.
Released for 3.5M6. Darin, please verify. I'll reassess this fix with regards to bug 233643. At least the side-effects seen in bug 264842 are fixed.
Reopen.
Created attachment 125940 [details] Proposed fix Darin, please give it a try before I release.
I found incremental build not working as expected. For example, if I remove #getLabel() from IHunk, no error appears in incremental build, but full build does find the problem (for org.eclipse.compare).
Similarly, fixing the problem did not make the issue go away on org.eclipse.compare (incremental biuld).
(In reply to comment #17) > I found incremental build not working as expected. For example, if I remove > #getLabel() from IHunk, no error appears in incremental build, but full build > does find the problem (for org.eclipse.compare). It works fine for me. In both ways, adding or removing the method works. I get an error reported against org.eclipse.compare.
Verified this works in my target workspace (I could not revalidate in the host due to a p2 bug).
