Community
Participate
Working Groups
- Window > Preferences > Plug-in development > API Baselines -> Missing API baseline --- set this to 'Error' - Let the workspace build and come to a stable state - Now go and change the preference to 'Warning' => On clicking ok, a dialog will popup asking for a full build. (you can also start with the preference set to Warning and then change it to error) Two things 1. Is is not possible to remove the existing error marker and create a new warning marker without doing a rebuild ? 2. When a full build is triggered all the projects are compiled again. Is running the Java builder again really necessary (no Java code has changed)? Shouldn't only the API analysis builder be run?
Good catch! That's probably simply because it's on the same page as the baselines itself.
See also bug 344163.
> 1. Is is not possible to remove the existing error marker and create a new > warning marker without doing a rebuild ? No, the API builder adds / removes markers, so to change them we have to run a build There is definitely some room for improvement here. I dug into this a bit and there are a few issues: 1. we should be asking for an incremental build (with only the API builder) job when we only change the preference. 2. we need to ensure that the error markers are refreshed even if we have an incremental build on the project with no types to build. For example, with the current code, I changed the pref block to only ask for an incremental build when only the preference was changed and the resulting build would not refresh the markers because no types were changed (the build context was empty).
(In reply to comment #3) > > 1. Is is not possible to remove the existing error marker and create a new > > warning marker without doing a rebuild ? > > No, the API builder adds / removes markers, so to change them we have to run a > build I disagree. This is a no-brainer: simply change the severity attribute of the marker. Note that this is only about the problem when the baseline is missing. I don't see any reason why a build would ever be needed to check whether a baseline is set or not.
(In reply to comment #0) > 2. When a full build is triggered all the projects are compiled again. This seems to be happening when I have o.e.jdt.core also in my workspace. When I was trying with only o.e.jdt.ui in my workspace, the Java code was NOT compiled again. Not sure why this happens, but o.e.jdt.core has project specific properties set for API Errors/Warnings and o.e.jdt.ui does not.
(In reply to comment #4) > I disagree. This is a no-brainer: simply change the severity attribute of the > marker. Its not a no-brainer, in the current form our builder handles all of our marker changes. We would have to change this to support changing markers produced by the builder.
Removing the default baseline (un-checking or deleting) we want to: 1. remove all binary compatibility markers from the project + all children 2. remove all version markers - they depend on binary ones from the project + all children 3. create a marker for a missing baseline - based on the severity 4. remove the API tools build state for the affected project -this is required because we store compatibility infos for version number checks We do not need to touch any of the other markers or run a build, since this preference change does not affect the API description of the project. Changing the severity of the missing baseline error: 1. if the new setting is not IGNORE find existing markers and update them to the new severity - if the new setting is ignore, just remove them we don't need a build for this one either.
Alright, we are on the same page now :)
(In reply to comment #5) > (In reply to comment #0) > > 2. When a full build is triggered all the projects are compiled again. > > This seems to be happening when I have o.e.jdt.core also in my workspace. When > I was trying with only o.e.jdt.ui in my workspace, the Java code was NOT > compiled again. > > Not sure why this happens, but o.e.jdt.core has project specific properties set > for API Errors/Warnings and o.e.jdt.ui does not. I can't reproduce this today, though will keep an eye out for it.
(In reply to comment #7) :-)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is still an issue in 4.12 M1.
New Gerrit change created: https://git.eclipse.org/r/146313
New Gerrit change created: https://git.eclipse.org/r/146339
Gerrit change https://git.eclipse.org/r/146339 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=646b4021abb3c5a8df38223b1dc8ed8f2032d5f9
Can either bug submitter or bug assignee ( if different) please verify this defect?
verified on Version: 2019-09 (4.13) Build id: I20190819-2355
