Community
Participate
Working Groups
I just migrated my RCP application from Oxygen to Photon. Everything worked fine on Photon. All of a sudden, my build on travis stopped working. It complains about "signer information does not match signer information of other classes in the same package". You can see the full log of the travis build here [1]. The code is here [2]. I do not think that the issue is within my code. Seems to be related to the repository? [1]: https://travis-ci.org/RobertHilbrich/assist-public/builds/397952071 [2]: https://github.com/roberthilbrich/assist-public Any ideas or pointer are greatly appreciated.
Downloaded from central: https://repo.maven.apache.org/maven2/org/eclipse/emf/org.eclipse.emf.codegen/maven-metadata.xml (737 B at 26 kB/s) [WARNING] Error injecting: org.eclipse.xtend.maven.XtendCompile com.google.inject.ProvisionException: Unable to provision, see the following errors: 1) Error injecting constructor, com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: java.lang.SecurityException: class "org.eclipse.core.runtime.OperationCanceledException"'s signer information does not match signer information of other classes in the same package at org.eclipse.xtend.maven.XtendCompile.<init>(Unknown Source) while locating org.eclipse.xtend.maven.XtendCompile 1 error at com.google.inject.internal.InjectorImpl$2.get (InjectorImpl.java:1025) at com.google.inject.internal.InjectorImpl.getInstance (InjectorImpl.java:1051) at org.eclipse.sisu.space.AbstractDeferredClass.get (AbstractDeferredClass.java:48) at com.google.inject.internal.ProviderInternalFactory.provision (ProviderInternalFactory.java:81) at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision (InternalFactoryToInitializableAdapter.java:53) at com.google.inject.internal.ProviderInternalFactory$1.call (ProviderInternalFactory.java:65) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision (ProvisionListenerStackCallback.java:115) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision (ProvisionListenerStackCallback.java:133) at com.google.inject.internal.ProvisionListenerStackCallback.provision (ProvisionListenerStackCallback.java:68) at com.google.inject.internal.ProviderInternalFactory.circularGet (ProviderInternalFactory.java:63) at com.google.inject.internal.InternalFactoryToInitializableAdapter.get (InternalFactoryToInitializableAdapter.java:45) at com.google.inject.internal.InjectorImpl$2$1.call (InjectorImpl.java:1016) at com.google.inject.internal.InjectorImpl.callInContext (InjectorImpl.java:1092) at com.google.inject.internal.InjectorImpl$2.get (InjectorImpl.java:1012) at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162) at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81) at org.eclipse.sisu.plexus.LazyPlexusBean.getValue (LazyPlexusBean.java:51) at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:263) at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:255) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo (DefaultMavenPluginManager.java:519) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) Caused by: com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: java.lang.SecurityException: class "org.eclipse.core.runtime.OperationCanceledException"'s signer information does not match signer information of other classes in the same package
Already reported as https://github.com/eclipse/xtext/issues/1231 Workaround is described there too
Created attachment 274683 [details] Sample Priject with main showing the error Problem is: the platform metadata allow to use this combination <dependencies> <dependency> <groupId>org.eclipse.platform</groupId> <artifactId>org.eclipse.core.runtime</artifactId> <version>3.14.0</version> </dependency> <dependency> <groupId>org.eclipse.platform</groupId> <artifactId>org.eclipse.equinox.common</artifactId> <version>3.8.0</version> </dependency> </dependencies> caus core.runtime specifies <dependency> <groupId>org.eclipse.platform</groupId> <artifactId>org.eclipse.equinox.common</artifactId> <version>[3.8.0,4.0.0)</version> </dependency> but at runtime equinox.common is needed. Exception in thread "main" java.lang.SecurityException: class "org.eclipse.core.runtime.ILog"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:898) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:668) at java.lang.ClassLoader.defineClass(ClassLoader.java:761) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
but at runtime equinox.common 3.10 is needed.
"signer information does not match signer information" is a sure indication of a mix-and-match installation, possibly due to crazy user dependencies, more commonly due to a bad platform build. There was a bad platform build at this time: See Bug 531640
no in this case the problem is bad dependency ranges that allow older and newer jars that are split packages to be used together. imho the ranges should have been updated with the signing change
Ouch! IMHO the 'master' consumer should have accurate version ranges so that everyone else can be open. Certainly those who use split packages must be very careful to guarantee the quality to their consumers. Further comment on the need for better platform testing added to Bug 466991.
New Gerrit change created: https://git.eclipse.org/r/125314
Gerrit change https://git.eclipse.org/r/125314 was merged to [master]. Commit: http://git.eclipse.org/c/viatra/org.eclipse.viatra.git/commit/?id=8b43b496d4d16e736b4cc2b90acf9a2900f8483f
*** Bug 536600 has been marked as a duplicate of this bug. ***
> but at runtime equinox.common 3.10 is needed. just FYI to anyone else hitting this problem, as noted on https://github.com/eclipse/xtext/issues/1231#issuecomment-402193047, for use in https://jira.opendaylight.org/browse/ODLPARENT-156 the solution was to slap a dependency to org.eclipse.jdt.core:3.13.102 (and not just org.eclipse.equinox.common:3.10.0) on the xtend-maven-plugin:2.14.0.
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/125314 was merged to [master]. > Commit: > http://git.eclipse.org/c/viatra/org.eclipse.viatra.git/commit/?id=8b43b496d4d16e736b4cc2b90acf9a2900f8483f > So, is this fixed? Also, please move to the correct component.
there is nothing fixed. https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.core.runtime/META-INF/MANIFEST.MF still has the range that allows the bad combinations of the platform maven artifacts
all the "fixes" in other components are just mitigations
(In reply to Christian Dietrich from comment #13) > there is nothing fixed. > https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org. > eclipse.core.runtime/META-INF/MANIFEST.MF > still has the range that allows the bad combinations > of the platform maven artifacts Do you have a proposal for "good" range?
(In reply to Christian Dietrich from comment #13) > there is nothing fixed. > https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.core.runtime/META-INF/MANIFEST.MF > > still has the range that allows the bad combinations > of the platform maven artifacts OK. Can you provide a Gerrit change.
if the maven artifact needs 3.10 to be fine with the signatures then it should start there. i am not sure when and how signatures change so when the problem will occur again in a different form for other dependencies. we will fix that on xtext side by beeing more restrictive in that platform and jdt versions we use to avoid future problems but others might be affected too.
(In reply to Christian Dietrich from comment #17) > we will fix that on xtext side by beeing more restrictive in that platform This seems very undesirable. Xtext is not synchronized with SimRel and makes occasional (accidental) breaking API changes. It is therefore very desirable to continue the prevailing practice of allowing an Xtext developer to use their favourite version of Xtext. I'm not clear why this an Xtext problem at all; conventional Xtext bounds should mean that it picks up the latest, which should be consistent and good. Unless Xtext is actually adding a fragment to a platform package, how is a bad platform signing an Xtext problem? The platform fragments should surely be tightly and unambiguously coupled to what they apply to. Also any plausible build repo should only offer a compatible set of top versions. (Perhaps the erroneous default ordering fixed by Bug 535509 is relevant)
This affects the maven and gradle part of Xtext. E.g. if you use the gradle part of Xtext With photon jdt it will be a factor 1000 slower and memory hungrier than with oxygen 3a. Since we use some internal api too we cannot take the latest greatest of everything In the particular problem the problem is that we partially take the latest and partially not. The ranges in jdt allow that. But the signatures do not.
Christian, once again: can you propose *better* ranges for platform plugins? If not: why?
It is for me mainly a i don’t have time and a we dont have solved this on Xtext side yet problem
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=635f01ccfe1d762c88d6108199bfecda3e47894b
(In reply to Dani Megert from comment #22) > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=635f01ccfe1d762c88d6108199bfecda3e47894b This caused API error: The minor version should be incremented in version 3.14.100, because the modification of the version range for the re-exported bundle org.eclipse.equinox.app requires a minor version change I will try to fix this now.
New Gerrit change created: https://git.eclipse.org/r/126523
Gerrit change https://git.eclipse.org/r/126523 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=fe47fe209e1606499f30c88595e60b8c3028b223
(In reply to Eclipse Genie from comment #25) > Gerrit change https://git.eclipse.org/r/126523 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > ?id=fe47fe209e1606499f30c88595e60b8c3028b223 In master. The error was reported also here: http://download.eclipse.org/eclipse/downloads/drops4/I20180723-2000/apitools/analysis/html/org.eclipse.core.runtime/report.html
(In reply to Andrey Loskutov from comment #23) > (In reply to Dani Megert from comment #22) > > Fixed with > > http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/ > > ?id=635f01ccfe1d762c88d6108199bfecda3e47894b > > This caused API error: The minor version should be incremented in version > 3.14.100, because the modification of the version range for the re-exported > bundle org.eclipse.equinox.app requires a minor version change > > I will try to fix this now. Thanks for fixing this. I will have to check why no error or warning appears in my workspace.
