Starting the OTDT with -configuration causes NoClassDefFoundError AdaptorActivator

[stephan]

Spawned from http://www.objectteams.org/hypermail/otj-users/0227.html by Carsten Pfeiffer

When sharing an eclipse installation for different configurations which are then selected using the -configuration command line option, the OTDT can be installed (from the update site), but during operation the following errors are logged:

!ENTRY org.objectteams.otequinox.hook 2 0 2009-10-04 18:30:33.540
!MESSAGE >>> adapting aspect bundles not yet wired when loading: org.objectteams.otdt.compiler.adaptor.AdaptorActivator

!ENTRY org.eclipse.core.resources 4 2 2009-10-04 18:30:33.541
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NoClassDefFoundError: org/objectteams/otdt/compiler/adaptor/AdaptorActivator
        at org.eclipse.jdt.core.JavaCore._OT$newLibraryEntry$chain(JavaCore.java)
        at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java)
        at org.eclipse.jdt.internal.core.ClasspathEntry.elementDecode(ClasspathEntry.java:737)
        at org.eclipse.jdt.internal.core.JavaProject.decodeClasspath(JavaProject.java:878)
        at org.eclipse.jdt.internal.core.JavaProject.readFileEntriesWithException(JavaProject.java:2444)
        at org.eclipse.jdt.internal.core.JavaModelManager$PerProjectInfo.readAndCacheClasspath(JavaModelManager.java:1185)
        at org.eclipse.jdt.internal.core.DeltaProcessor.readRawClasspath(DeltaProcessor.java:483)
        at org.eclipse.jdt.internal.core.DeltaProcessor.checkProjectsAndClasspathChanges(DeltaProcessor.java:322)
        at org.eclipse.jdt.internal.core.DeltaProcessor.checkProjectsAndClasspathChanges(DeltaProcessor.java:463)
        at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1901)
        at org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:470)
        at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:291)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
        at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
        at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313)
        at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1809)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782)
        at org.eclipse.pde.internal.ui.samples.SampleOperation._OT$run$orig(SampleOperation.java:92)
        at org.eclipse.pde.internal.ui.samples.SampleOperation._OT$run$chain(SampleOperation.java)
        at org.eclipse.pde.internal.ui.samples.SampleOperation._OT$run$chain(SampleOperation.java)
        at org.eclipse.pde.internal.ui.samples.SampleOperation.run(SampleOperation.java)
        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: java.lang.ClassNotFoundException: org.objectteams.otdt.compiler.adaptor.AdaptorActivator
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
        at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
        at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        ... 24 more

Reproducable in trunk.

[stephan]

Here's another interesting log entry:

!ENTRY org.objectteams.otequinox.hook 4 0 2009-10-04 18:29:39.936
!MESSAGE Found more than one version of adapted base bundle org.eclipse.jdt.core.

This means, that our patch feature failed to effectively override the original jdt.core. This seems to indicate that we have a "mild form of" Eclipse bug 281510! In that bug, a patch feature did not succeed without write permission to the central eclipse installation. In the case of this bug the patch feature installs fine, but fails to disable the replaced bundle. So now we have two versions of org.eclipse.jdt.core and the aspect cannot decide which one to adapt.

Interestingly, when I know launch the OTDT with -Dot.equinox=false this bare-bone version actually works, and our compiler is in place and running. This means I can probably work around the problem within OT/Equinox.

[stephan]

The issue analyzed in comment 1 is fixed in r22688 be selecting the highest version base plugin.

Using this patch I was able to install the OTDT into an Eclipse with -configuration and everything seemed to work fine.

[stephan]

backported to 1.3.x in r22691

[stephan]

An update has been uploaded to http://www.objectteams.org/distrib/otdt-updates-unstable

This requires an Eclipse 3.5.1 plus the two newest features from the above site:

• Object Teams Development Tooling 1.3.2.200909280002
• OT/Equinox 1.3.3.200910050150

I recommend to de-select "Contact all sites during install ..." ;-)