Community
Participate
Working Groups
I started a 4.2.2 build this morning (I pulled in the latest submodule branch tip) and it failed on [INFO] org.eclipse.jdt.core.tests.model .................. FAILURE [30.221s] It doesn't matter if I run locally or with signing on build.eclipse.org. The failure error is: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-plugin:0.17.0-SNAPSHOT:p2-metadata-default (default-p2-metadata-default) on project org.eclipse.jdt.core.tests.model: Execution default-p2-metadata-default of goal org.eclipse.tycho:tycho-p2-plugin:0.17.0-SNAPSHOT:p2-metadata-default failed: 6 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-p2-plugin:0.17.0-SNAPSHOT:p2-metadata-default (default-p2-metadata-default) on project org.eclipse.jdt.core.tests.model: Execution default-p2-metadata-default of goal org.eclipse.tycho:tycho-p2-plugin:0.17.0-SNAPSHOT:p2-metadata-default failed: 6 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-p2-metadata-default of goal org.eclipse.tycho:tycho-p2-plugin:0.17.0-SNAPSHOT:p2-metadata-default failed: 6 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 6 at org.objectweb.asm.ClassReader.readShort(ClassReader.java:2057) at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166) at org.objectweb.asm.ClassReader.<init>(ClassReader.java:153) at org.eclipse.tycho.zipcomparator.internal.ClassfileComparator.disassemble(ClassfileComparator.java:62) at org.eclipse.tycho.zipcomparator.internal.ClassfileComparator.getDelta(ClassfileComparator.java:50) at org.eclipse.tycho.zipcomparator.internal.ZipComparatorImpl.getDelta(ZipComparatorImpl.java:88) at org.eclipse.tycho.zipcomparator.internal.ZipComparatorImpl.getDelta(ZipComparatorImpl.java:36) at org.eclipse.tycho.plugins.p2.BaselineValidator.getDelta(BaselineValidator.java:226) at org.eclipse.tycho.plugins.p2.BaselineValidator.validateAndReplace(BaselineValidator.java:88) at org.eclipse.tycho.plugins.p2.P2MetadataMojo.attachP2Metadata(P2MetadataMojo.java:146) at org.eclipse.tycho.plugins.p2.P2MetadataMojo.execute(P2MetadataMojo.java:104) at org.eclipse.tycho.plugins.p2.P2MetadataDefaultMojo.execute(P2MetadataDefaultMojo.java:34) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more This build was run with: mvn -DbuildId=M20121126-0822 -X -Pbree-libs clean install -Dmaven.test.skip=true -Dmaven.repo.local=$LOCAL_REPO We're running with the build qualifier from jgit plugin. We just changed the configuration to exclude pom.xml and generate longer qualifiers, so more bundles are now being compared against the baselineRepo than before: <configuration> <strictBinIncludes>false</strictBinIncludes> <format>'v'yyyyMMdd-HHmmss</format> <timestampProvider>jgit</timestampProvider> <jgit.ignore> pom.xml </jgit.ignore> <sourceReferences> <generate>true</generate> </sourceReferences> </configuration>
I think I saw this before. jdt tests have some purposely malformed classes and Tycho is supposed to fall back to byte-to-byte comparison when running into such files. Not sure why it throws an exception instead.
Anyway we can have this fixed? We need this for the Platform CBI cutover.
I won't have time to look at this in the near future unless somebody provides patch+regression test.
as a workaround, you should be able to disable reproducible qualifier logic for org.eclipse.jdt.core.tests.model project. I am guessing reproducible qualifiers for test projects are not strictly required.
I was able to workaround by changing the timestamp provider for org.eclipse.jdt.core.tests.model using the snippet below. <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-packaging-plugin</artifactId> <version>${tycho.version}</version> <configuration> <timestampProvider>default</timestampProvider> </configuration> </plugin>
New Gerrit change created: https://git.eclipse.org/r/68471
Is there an easy way to reproduce this issue using the JDT project? Looking into the code and reading through the comments, I am pretty sure that the submitted fix will solve the issue, but if it is easy to do with JDT, I would like to test the fix with that as well.
(In reply to Martin Schreiber from comment #7) > Is there an easy way to reproduce this issue using the JDT project? Looking > into the code and reading through the comments, I am pretty sure that the > submitted fix will solve the issue, but if it is easy to do with JDT, I > would like to test the fix with that as well. Not sure it is "easy", but if it is helpful to you, I can give you some details. This is the bundle that has the intentionally bogus classes: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.model You'll notice its pom has a "workaround" in it to specify the "default" timestampProvider. http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.model/pom.xml#n38 What that does in "increment" the qualifier each build. Otherwise -- if we used the eclipse parent defaults then the qualifier will be the same, which causes the "comparator" to kick in and tries to "read" the classes of current build, and previous build (with the same qualifier) to compare the two, to make sure they are the same, since the qualifier is the same. Since that comparator throws an exception, we have to increment the qualifier each build to avoid invoking the comparator. (And, before you ask :) I am not sure which class file in the test bundle is the bogus one -- there is probably more than one?) Is this the type of information you were after?
Gerrit change https://git.eclipse.org/r/68471 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=215a17d0035d2d384b1b9049ebd8253f2a9568df
Issue resovled with the gerrit commit noted above
