• Bug
  • Status: Closed
  • 2 Major
  • Resolution: As Designed
  • Eclipse Plugin
  • gkeim
  • Reporter: wharley
  • July 22, 2008
  • 0
  • Watchers: 0
  • July 27, 2012
  • July 29, 2008

Description

Installed nightly build (rev9424) of Eclipse plugin in the ‘dropins’ folder per Ganymede (Eclipse 3.4) recommendations. Added Terracotta nature to a project and clicked finish. Received following stack trace.

Note that ‘dropins’ is a new thing for Ganymede; it is no longer recommended to put third-party plugins directly into the ‘plugins’ folder, because of the new provisioning code (aka p2).

I suspect that what’s going on is that TC is using the bundle location as a way of building a path to somewhere to store config information. This is not ideal Eclipse practice; rather, APIs like Plugin.getStateLocation, Platform.getConfigurationLocation, or Platform.getInstallLocation are probably better, if that’s in fact the issue.

org.eclipse.core.runtime.AssertionFailedException: assertion failed: Path for IClasspathEntry must be absolute: file:/Developer/Applications/eclipse/dropins/deploy/build.eclipse/src.classes at org.eclipse.core.runtime.Assert.isTrue(Assert.java:111) at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:4013) at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:3901) at org.eclipse.jdt.launching.JavaRuntime.newArchiveRuntimeClasspathEntry(JavaRuntime.java:610) at org.terracotta.dso.ClasspathProvider.computeUnresolvedClasspath(ClasspathProvider.java:49) at org.eclipse.jdt.internal.launching.RuntimeClasspathProvider.computeUnresolvedClasspath(RuntimeClasspathProvider.java:53) at org.eclipse.jdt.launching.JavaRuntime.computeUnresolvedRuntimeClasspath(JavaRuntime.java:1173) at org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate.getBootpathExt(AbstractJavaLaunchConfigurationDelegate.java:301) at org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate.getVMSpecificAttributesMap(AbstractJavaLaunchConfigurationDelegate.java:568) at org.eclipse.jdt.launching.JavaLaunchDelegate.launch(JavaLaunchDelegate.java:68) at org.terracotta.dso.BootJarHelper.getBootJarName(BootJarHelper.java:92) at org.terracotta.dso.actions.BuildBootJarAction.doFinish(BuildBootJarAction.java:143) at org.terracotta.dso.actions.BuildBootJarAction.run(BuildBootJarAction.java:102) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Comments

Gary Keim 2008-07-22

I think the problem is that the DSO plug-in must be extracted. The exception implies that it thinks it’s being run in a development environment because it can’t locate PLUGIN_DIR/lib/tc.jar. So, it’s trying to provide access to the classes found in the tcbuild project structure.

At one point it needed to be extracted because the bootjar was being created in the default location. Since then the bootjar is always created in the user project area. Not sure if using archive-relative URLs works everywhere. plugin.jar /lib/tc.jar.

Walter Harley 2008-07-22

It may actually be possible to get all that working without needing to manually expand the jar; Eclipse can automatically unpack and cache the necessary stuff programatically, under certain circumstances. I’ve got the relevant code somewhere (in the org.eclipse.jdt.apt.tests plugin), will try to dig it up so you can see if it would be useful.

Fiona OShea 2008-07-23

see if we can get this working. Let DRB know if you need further info/help.