Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Baseline Tycho error?
Hi Marc-Andre and the rest of the team,

I agree that the default should be changed. I was sort of wondering about it when I mentioned it in the last email, so I am glad you shared your thoughts too.

The default has now changed on master and cdt_9_8 branch. If you want to run with baseline replace you need to add baseline-compare-and-replace profile to Maven command line.

If you don't have this profile enabled, you should see this repeated for each plug-in showing that it is skipped:

[INFO] --- tycho-p2-plugin:1.4.0:p2-metadata (attached-p2-metadata) @ org.eclipse.cdt.core ---
[INFO] 
[INFO] --- tycho-p2-plugin:1.4.0:p2-metadata (baselinereplace-p2-metadata) @ org.eclipse.cdt.core ---
[INFO] 
[INFO] --- tycho-p2-extras-plugin:1.4.0:compare-version-with-baselines (compare-attached-artifacts-with-release) @ org.eclipse.cdt.core ---
[INFO] Skipped
[INFO]

This change should make it easier for people to build locally. However local builds without the profile enabled will not warn/error about failing to update version numbers. The gerrit build will continue to check for that.

Thanks
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 28 Jun 2019 at 00:15, Marc-Andre Laperle <malaperle@xxxxxxxxx> wrote:
Hi Jonah,

Thanks a lot for looking into this! I updated my master and indeed the new profile does work.
I do feel like this should be the default as you need a carefully set up environment (i.e. Java version) and the Eclipse CI infrastructure is in the best position to do this check because it was responsible for producing the released bits (baseline) in the first place. If anyone wants to make custom build to be released outside the Eclipse CBI and use the baseline feature then one would likely have to override the comparator.repo with something that was generated in a similar environment to what is being built. This doesn’t sound usual and like something normal contributors should have to worry about.

I only have a superficial understanding of how this stuff works so hopefully that makes sense :)

Regards,
Marc-André

On Jun 26, 2019, at 11:07 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

TL;DR:

Update your master (or cdt_9_8) branch and add -Pskip-baseline  to your command line.

--- Details ---

It looks like a difference in Java versions - I reproduced with Java 11.0.3. 

I don't have the problem with the following java, which is the same as the build machine.
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.16.04.1-b03)
OpenJDK 64-Bit Server VM (build 25.212-b03, mixed mode)

I think the problem is a change in the library, so you do get legitamely different bytecode:

The baseline has this:
     104: invokevirtual #126                // Method java/nio/CharBuffer.limit:(I)Ljava/nio/Buffer;
and the java 11 build has:
     104: invokevirtual #110                // Method java/nio/CharBuffer.limit:(I)Ljava/nio/CharBuffer;

This appears to be because in Java 11, CharBuffer now overrides limit. That difference is what I think causes StringRider to be rejected as different. I haven't bothered to look into precise diff of REDTextStore and I don't know what the other version of Java 8 you are using provides so many differences.

We need a way on your local build to be able to skip baseline replace & compare. After lots of playing around I decided the best thing to do was add a new profile that makes setting all the options in one go easier. You can now use skip-baseline profile to do that. See tycho compare docs and tycho replace docs for more info on what is being set on the profile. (Open question is if this should be the default, and only on build machine should we do compare and replace?)

If this is a new problem you are experiencing, it is probably down to be changing the reported error from what used to be a warning. It turned out that in the past, if there were bytecode differences, but no source differences, the build would report warning about mismatch, but do the replace anyway. See Bug 547894. Before this bug was fixed, it was sufficient to just add -Dcompare-version-with-baselines.skip=true to get build to pass, but it would have been (potentially) building a bad result.

Jonah



On Tue., Jun. 25, 2019, 23:27 Marc-Andre Laperle, <malaperle@xxxxxxxxx> wrote:
Hi,
I get this error when I do a local Tycho build. Does anyone know how to solve this?

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-plugin:1.4.0:p2-metadata (baselinereplace-p2-metadata) on project org.eclipse.cdt.dsf.ui: baseline and build artifacts have same version but different contents
[ERROR]    no-classifier: different
[ERROR]       org/eclipse/cdt/dsf/debug/internal/ui/disassembly/text/REDTextStore.class: different
[ERROR]       org/eclipse/cdt/dsf/debug/internal/ui/disassembly/text/StringRider.class: different

Could it be a mismatch with the Java versions used to compile my local copy versus the baseline?
I tried Java 11.0.3 (above output) and Java 1.8.0_181 (even more similar errors).

Thanks a lot,

Marc-André
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
 
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top