Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320191

Summary:	[pde] Exporting an OT plug-in requires to have org.eclipse.objectteams.runtime in the ws
Product:	[Tools] Objectteams	Reporter:	Stephan Herrmann <stephan.herrmann>
Component:	OTDT	Assignee:	Stephan Herrmann <stephan.herrmann>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	iloncar.ml
Version:	0.7
Target Milestone:	0.7.1
Hardware:	PC
OS:	Linux
Whiteboard:

Description Stephan Herrmann

2010-07-18 10:38:42 EDT

Interactively exporting an OT plug-in using the wizard may fail with errors like:

"The type org.objectteams.IBaseMigratable cannot be resolved. It is
indirectly referenced from required .class files"

This indicates that the scripted compile doesn't find the OTRE.

This can be worked around by importing the org.eclipse.objectteams.runtime
plug-in into the workspace, e.g.:
  Import ... >  Plug-in Development > Plug-ins and Fragments 
  (x) Import from the active target platform ...
  (x) Select from all ...
  (x) Binary projects
  -> org.eclipse.objectteams.runtime > Finish

Need to check how pde-build resolves the OTRE, perhaps it has difficulties
with the nested jar?

Comment 1 Stephan Herrmann

2010-07-18 10:41:52 EDT

Another - simpler - workaround is checking the following option within the 
export wizard:

Options > [x] Use class files compiled in the workspace.

Comment 2 Stephan Herrmann

2010-07-18 11:17:20 EDT

Here are some potentially related bugs:

Bug 103136 -  PDE seems to be unable to handle so-called jar'ed library plugins deployed in target platform.

Bug 147831 -  [compiler] failed to find classes wrapped in a bundle

Bug 157375 -  PDE should support building against nested JARs

The OTDT expands the OTRE classpath container to s.t. like
 configuration/org.eclipse.osgi/bundles/427/1/.cp/lib/otre.jar
(see org.eclipse.objectteams.otdt.core.ext.OTREContainer)
Somehow, this expansion seems not to be used for ant-based compilation.

I'm not sure at this moment how importing the binary runtime makes a
differences.

Comment 3 Ivica Loncar

2010-07-20 14:32:06 EDT

Stephan, thanks for opening the issue. 

I've used the second workaround (classes compiled in the workspace).

Comment 4 Stephan Herrmann

2010-07-23 18:02:59 EDT

Problem has been resolved by a change in how the OTRE is built and packaged:
Instead of building three jars outside the automated build (otre.jar,
otre_min.jar, otre_agent.jar), the source have been migrated into the
org.eclipse.objectteams.runtime plugin, and thus the OTRE is by default
a plugin now (i.e., no more otre.jar only the plugin jar exists).

The main benefit lies in the fact that we're no longer using nested jars,
which fixes this bug.

Additionally, all three jars are now created via PDE/Build (with 
customBuildCallbacks for jar-ing otre_min.jar and otre_agent.jar).

This change is implemented between r587 and r636:
 + move sources from OTRE to org.eclipse.objectteams.runtime
 + adjust the plugin configuration and build scripts
 + update implementation of classpath container "OTRE"
   - discard useless variable "OTRUNTIME_LIBDIR"
   - add logic to check existence of "bin/" folder in runtime plugin,
     if found use this for "OTRE" otherwise the resolved plugin itself.

Note, that when releasing this change, documentation for running OT/J
programs outside Eclipse needs updating, too, to refer to the plugin
instead of otre.jar.

Comment 5 Stephan Herrmann

2010-09-22 17:42:24 EDT

Verified using I201009211735