Community
Participate
Working Groups
This has been reported on epp-dev [1]. It is a consequence of Bug 472897, i.e., the use of @Nullable annotations. [1] <http://dev.eclipse.org/mhonarc/lists/epp-dev/msg03813.html>
FYI, here's the actual exception: org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: org/eclipse/jdt/annotation/Nullable at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:386) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:294) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162) at org.eclipse.epp.internal.logging.aeri.ide.Startup$1.run(Startup.java:40) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.NoClassDefFoundError: org/eclipse/jdt/annotation/Nullable at org.eclipse.epp.internal.logging.aeri.ui.model.impl.ModelPackageImpl.initializePackageContents(ModelPackageImpl.java:2002) at org.eclipse.epp.internal.logging.aeri.ui.model.impl.ModelPackageImpl.init(ModelPackageImpl.java:326) at org.eclipse.epp.internal.logging.aeri.ui.model.IModelPackage.<clinit>(IModelPackage.java:65) at org.eclipse.epp.internal.logging.aeri.ui.utils.Constants.<clinit>(Constants.java:53) at org.eclipse.epp.internal.logging.aeri.ui.functions.RegistryServersCreationFunction.compute(RegistryServersCreationFunction.java:49) at org.eclipse.e4.core.internal.contexts.ValueComputation.get(ValueComputation.java:62) at org.eclipse.e4.core.internal.contexts.EclipseContext.internalGet(EclipseContext.java:247) at org.eclipse.e4.core.internal.contexts.EclipseContext.get(EclipseContext.java:213) at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier.fillArgs(ContextObjectSupplier.java:194) at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier.get(ContextObjectSupplier.java:178) at org.eclipse.e4.core.internal.di.InjectorImpl.resolveArgs(InjectorImpl.java:505) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:368) ... 4 more Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.annotation.Nullable cannot be found by org.eclipse.epp.logging.aeri.ui_1.100.0.v20151216-0616 at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:444) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:349) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 16 more
Some more details: The org.eclipse.epp.logging.aeri.ui bundle imports org.eclipse.jdt.annotations like this: Require-Bundle: org.eclipse.jdt.annotation;bundle-version="[1.0.0,2.0.0)";resolution:=optional But ModelPackageImpl.initializePackageContents contains this line initEDataType(nullableEDataType, Nullable.class, "Nullable", IS_SERIALIZABLE, !IS_GENERATED_INSTANCE_CLASS); The explicit Nullable.class reference is the problem; the annotation need not be on the classpath due to resultion:=optional. I am unfortunately not an ECore/EMF expert, so I don't know how to teach it to use the annotation in the generated code to annotate methods with but not as a class literal in methods like initializePackageContents.
(In reply to Andreas Sewe from comment #2) > I am unfortunately not an ECore/EMF expert, so I don't know how to teach it > to use the annotation in the generated code to annotate methods with but not > as a class literal in methods like initializePackageContents. FYI, asked on the ECore forum how to tweak code generation for compilet-time annotations [1]. [1] <https://www.eclipse.org/forums/index.php/m/1717972/#msg_1717972>
New Gerrit change created: https://git.eclipse.org/r/63010
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/63010 This implements just a *workaround*. The org.eclipse.jdt.annotations bundle should really be a compile-time dependency, but the ECore generated code currently forces it to be a runtime dependency. However, until someone with more ECore knowledge has time to look at it, it may serve.
New Gerrit change created: https://git.eclipse.org/r/63020
In Trace Compass, we depend on null annotations only at compile by only adding them to build.properties, not manifest.mf. For example: http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/tree/common/org.eclipse.tracecompass.common.core/build.properties
(In reply to Marc-Andre Laperle from comment #7) > In Trace Compass, we depend on null annotations only at compile by only > adding them to build.properties, not manifest.mf. For example: > http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/tree/ > common/org.eclipse.tracecompass.common.core/build.properties Thanks for the pointer. That is certainly an option *if* we can get ECore to not generate code not referencing the Nullable.class literal. Any idea how to do that?
(In reply to Andreas Sewe from comment #8) > (In reply to Marc-Andre Laperle from comment #7) > > In Trace Compass, we depend on null annotations only at compile by only > > adding them to build.properties, not manifest.mf. For example: > > http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/tree/ > > common/org.eclipse.tracecompass.common.core/build.properties > > Any idea how to do that? Oh! No, sounds more complicated! I have no experience in ECore generated code (or even anything advanced using annotations). But...maybe you can do Nullable.class.getAnnotations(), check if has @Retention(RetentionPolicy.CLASS) ? Probably good to check that for any classes actually!
(In reply to Marc-Andre Laperle from comment #9) > Oh! No, sounds more complicated! I have no experience in ECore generated > code (or even anything advanced using annotations). But...maybe you can do > Nullable.class.getAnnotations(), check if has > @Retention(RetentionPolicy.CLASS) ? > Probably good to check that for any classes actually! Maybe I misunderstand you, but the Nullable.class.getAnnotations() call introduces (due to the class literal) a runtime dependency to the @Nullable annotation, even though it has RetentionPolicy.CLASS.
(In reply to Andreas Sewe from comment #10) > (In reply to Marc-Andre Laperle from comment #9) > > Oh! No, sounds more complicated! I have no experience in ECore generated > > code (or even anything advanced using annotations). But...maybe you can do > > Nullable.class.getAnnotations(), check if has > > @Retention(RetentionPolicy.CLASS) ? > > Probably good to check that for any classes actually! > > Maybe I misunderstand you, but the Nullable.class.getAnnotations() call > introduces (due to the class literal) a runtime dependency to the @Nullable > annotation, even though it has RetentionPolicy.CLASS. Or maybe I misunderstood you :) I'm talking about the generator code, not the generated code. I have no idea how this is done. In my head, it went like this: class ECoreCodeGenetator { void generateCode(Class clazz) { // magic! clazz.getAnnotations() ... // magic that decides not to generate initEDataType(Nullable.class) } But I have no knowledge about ECore and AERI, so I'll be quiet now :)
Gerrit change https://git.eclipse.org/r/63020 was merged to [master]. Commit: http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/commit/?id=a8d81dcc5ff327c2497848d46d404f1b4f958ab2
*** Bug 484891 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/63010 was merged to [master]. Commit: http://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/commit/?id=b1737b2b144fd69e4b2a9a80ee46c51cf7136485