oAW has moved to Eclipse.

Hi all,

again it has to do with invoking an xtend m2m-transformation using the JavaMetaModel.

Problem:

if I invoke my workflow via Platform - Run as oaw-Workflow it goes fine,

but

if I invoke the same workflow from my own plugin code, my self-defined type won't be resolved (using JavaMetaModel):

'Couldn't resolve type for javahelpers::AJavaClass'

I examined a lot and came to the conclusion, that the problem has to do with the used classloader. Debugging yields:

Platform - run as oaw: java.lang.classloader is used, knowing around 600 classes, everything, I might need ;-)

my plugin: org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader is used, but it does not know my javahelpers::AJavaClass :-(

I tried to add

Export-Package: javahelpers,
sampleplugin.ui,
sampleplugin.ui.popup.actions

to the manifest, but it still does not work...

Anyone some idea????

For testing, I uploaded my minimalistic plugin to tbuhr.de/oaw_javamm_sample.zip

Thanks for your time, Tobias

Isn't this the same issue, you had last week? :-)

You try to use classes contained in your eclipse project from the eclipse runtime, right?
The resources with in your workspace are not on the classpath of the eclipse runtime.

Hi Sven,

of course, you're right, but now I can exactly say, where the problem is... (the classloader itself)

and hope that knows a solution

Again, like that (as emf also does, but these metamodels are on the classpath somehow) they should be on the classpath:

Export-Package: javahelpers,
sampleplugin.ui,
sampleplugin.ui.popup.actions

but the DefaultClassLoader does not recognize them...

In Eclipse/OSGi every plugin (bundle) has its own classloader. From your plugin, you reference (i.e. Require_Bundle) the oaw workflow plugin, so your plugin knows about the workflow plugin's exported classes.

Since the workflow plugin does not reference your plugin, it cannot find your classes. It simply cannot, because

a) the workflow plugin does not know about your plugin at compile time
b) this would result in a circular dependeny

You could use Buddy classloaders to avoid this, but this requires to oaw workflow plugin to declare Buddy classloading in its MANIFEST. Sven should have a say on this.

Using a launch configuration avoid this problem, since it actually launches a separate VM to execute the workflow, and in this VM, there is no Eclipse/OSGi environment and classloading works as expected: Anything you declare in your project's classpath can be found by anyone.

Hope this helps,
Achim

Hi Achim,

your answer describes sad facts

I found a solution, similar to your advice with the buddy policies:

I added my javahelpers as a required plugin to oaw.core.expression (where JavaMetaModel is declared) a now it works.. (I avoided the circular dependency by moving javahelpers into its own pluging).

Of course this is a kludge, but for now, I will use it that way.

Still I think, there must be a better way. When you think at the EMF-Metamodels, these are plugins not known by oaw directly, but will always be recognized correctly. (eg. EcoreUtil2.getEPackageByClassName("EcorePackage") finds the needed type)

Merry christmas, Tobias
// still will do some research on how EmfMetaModel does its type-finding (this works obviously better) -- but would be very happy about some experts helping...

Hi Tobias,

EMF Metamodels typically register themselves at the org.eclipse.emf.ecore.generated_package extension point or by calling EPackage.Registry.INSTANCE.put(, ); This way, anyone can query EMF about EPackages and their EClasses and instantiate them.

Cheers,
Achim