How to solve: "baseline and build for xyz.class have different contents" ? #2406
-
|
Hello everyone, and Here's the build: https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/1671/checks?check_run_id=30751318486 I'm pretty sure I read something about it in the official documentation but it was some time ago and I can't find the link anymore. I'm tempted to say that the solution is bumping the version of the plugin in its MANIFEST, in this case it would be:
Any hints? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 7 replies
-
|
The API baseline replacement stuff is quite fussy. Firstly, it does not like it when a new artifact is produced that has the same artifact ID (fully qualified version) as in the baseline(s). It also doesn't like a new artifact that has only a qualifier increment, so typically the first change to a bundle for a release cycle requires at least a micro/service increment (of 100). But after that, it's still possible that something changes, e.g., the compiler produces new different bytes. At this point there will again be complaints about the artifact being different but having the same version. So I think there are conceptually kind two baselines, the API baseline from the most-recent release, and the baseline from the already-published/publicized I-Builds) At this point just new qualifier is needed, not another micro/service increment. That's generally done by editing the forceQualifierUpdate.txt with some description/link/whatever for why the qualifier needs to be different. So, in general, when something changes, the artifact needs a new version. That version must be at least +100 from the API baseline and the qualifier needs to be bigger than the qualifier from any previous I-builds before the change... Someone should correct me on anything I've said that isn't entirely accurate! |
Beta Was this translation helpful? Give feedback.
-
No, you shouldn't. This should only happen in very seldom cases where the code change from one bundle affects compilation artifacts of another bundle (without breaking source code compile) and other bundle has no source changes. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, I don't ever recall needing to do this for a bundle. For a feature, when most still included 3rd party bundles, an update to the target platform often required such forced qualifiers for the including features. But we've mostly eliminated that... |
Beta Was this translation helpful? Give feedback.
-
|
So if a pull + rebase didn't solve the problem (I tried it) and touching |
Beta Was this translation helpful? Give feedback.
-
|
You should ask, it is hard to say which problem you had before and which might happen in the future. We permanently have infrastructure issues, tycho updates, github action changes, PDE bugs etc |
Beta Was this translation helpful? Give feedback.
-
|
Good point, the infrastructure is also a changing environment so asking is never a bad idea. Thank you all for the insights! I consider my question answered and I've learned something new in this discussion :-) |
Beta Was this translation helpful? Give feedback.
The API baseline replacement stuff is quite fussy. Firstly, it does not like it when a new artifact is produced that has the same artifact ID (fully qualified version) as in the baseline(s). It also doesn't like a new artifact that has only a qualifier increment, so typically the first change to a bundle for a release cycle requires at least a micro/service increment (of 100). But after that, it's still possible that something changes, e.g., the compiler produces new different bytes. At this point there will again be complaints about the artifact being different but having the same version. So I think there are conceptually kind two baselines, the API baseline from the most-recent release…