search

viatra / EMF-IncQuery

This repository is only kept for historic reasons. All development happens on eclipse.org
http://eclipse.org/viatra
13 stars 4 forks source link

Enable importing EPackages registered by target platform #256

Closed balazsgrill closed 11 years ago

balazsgrill commented 12 years ago

Hi!

When developing a product, we would like to define queries for models maintained by us. It would be much easier if the ieq file allowed us to import packages registered in the target platform instead of having to install it to the eclipse install used for development.

istvanrath commented 12 years ago

Hi Balázs!

As a workaround, you can go the "eiqgen" route, as described in the cheat sheet (-ci version). This will allow you to reference epackages that are available through .genmodel files in the workspace, OR (this is "undocumented") resolvable through a "platform:/" URI.

balazsgrill commented 12 years ago

Thanks for the fast reply! I've configured the eiqgen file, but it still won't work. Now the import "platform:/resource/..ecore" works, but does not find any of the EClasses ("Couldn't resolve EClassifier..). Importing packages by URI still won't work.

istvanrath commented 12 years ago

You need to refer to .genmodel files inside the generator.eiqgen.

balazsgrill commented 12 years ago

I did. I've also included the genmodel referenced by the other genmodel. Doing made the error message on the import by platform url line disappear, but it still cannot load any of the classes. And it still cannot import packages by URI.

istvanrath commented 12 years ago

Can you include some concrete code and models here so that we can reproduce this issue?

balazsgrill commented 12 years ago

I will try to reduce the problem in a simple example to be able to publish here.

balazsgrill commented 12 years ago

Here is the example: https://github.com/gbalage/junk/tree/EMFIncQuery

istvanrath commented 12 years ago

Thanks for the code. Can you provide some details on the configuration, i.e. which project is where (workspace, installed into host, available in some target platform, etc), what exactly is the error you are getting, etc.

balazsgrill commented 12 years ago

In the example, both projects are located in the workspace. The query.test.model contains the model, the genmodel and the generated code. The query project contains the generator.eiqgen, which refers to the genmodel file by platform resource URL. There are 2 errors in the eiq file:

If I import "http://Some.package", it does not show any error message, but it still cannot locate "A". (Which is in http://Some.package/subpackage)

ujhelyiz commented 11 years ago

I have some good news: the eiq file from https://github.com/balazsgrill/junk/blob/EMFIncQuery/query/src/Query.eiq compiles without errors after adding a missing semicolon at the end of line 4 - both in version 0.6.10 and 0.7 (after migrating the query project) - the EClassifier A is resolved correctly thanks to the eiqgen declaration.

balazsgrill commented 11 years ago

Confirmed, it works with the 0.7.0.201301101537 build. Thanks!

Though the issue is about using models from the target platform. I can work with eiqgen files, importing the model project is much less overhead than installing them to the development instance so just from curiosity, will the target platform models be supported in the future?

ujhelyiz commented 11 years ago

The main issue with the target platform is that it provides no way to efficiently query the defined EMF models during query editing - however it is needed for the editor features and (to a lesser extent) for code generation as well.

The installed EPackages are queried from the EPackage Registry (and/or registered Eclipse extensions) of the host Eclipse; the eiqgen-based resolution mechanism was added to be able to refer to any possible Ecore model using the URI mechanism.

However target platforms (see ITargetDefinition class from pde.core) only provide bundle-level information (e.g. see org.eclipse.equinox.frameworkadmin.BundleInfo). The main issue is that the interface does not provide information about neither extension points nor non-class files in bundles.

So my main issue is I don't really know how to support this case. Alltogether, I'm sorry, but I don't know how/when will target platforms correctly supported.

balazsgrill commented 11 years ago

Yes, I see the problem. Moreover the ecore and genmodel are not included by neither binary or source builds by default. But, the PDE API provides information about the packages int the target platform through the org.eclipse.pde.core.plugin.IPluginExtension interface.

The good side with this, that this API works the same way on every plug-in source (workspace, installation and target platform) The problem with it, that the builder needs to instantiate the EPackage implementations to query them. This would require to start (and maintain) an eclipse instance in the background.

It is hard but not impossible. If you could give me some details about how the IncQuery builder searches for packages and classes (or where to look for it), i can look into the issue.

ujhelyiz commented 11 years ago

There are two bound services called IMetamodelProvider and IEiqGenmodelProvider that are related to this resolution. There are multiple implementations for them that are selected based on various dependencies (e.g. the patternlanguage.emf project is totally independent of Eclipse). You can look at the provided implementations.

About your contribution: we are glad to accept it, if you are able to donate them (check legal issues), but we hope, our code base would migrate soon to eclipse.org infrastructure, so that issue would be solved there.

balazsgrill commented 11 years ago

Thanks for the info! I will start working on a fork which you can pull whenever you find it appropriate. About the legal issues: I can only offer my free time for this task, therefore it will not interfere with my employer.

balazsgrill commented 11 years ago

I was wrong in one thing: the binary builds of EMF model projects DO contain ecore and genmodel files by default. If we assume that they're available in plugins loaded into the target platform it makes the problem much simpler, as we can load these models painlessly.

There are two simple approaches available:

First, I've tried the second option:

https://github.com/balazsgrill/EMF-IncQuery/commit/92138db3df11b28d50620c9257e9c2565b76c45b

As there is no appropriate URI scheme to refer contents of plugins regardless of their location (resource:/plugin/.. URIs are used to reference installed plugins in the running instance), I've introduced a custom URI: "plugin:/some.model.plugin.id/location/of/model.genmodel".

The method these URIs are resolved is not elegant, but dead simple: they're exchanged with a file: or jar: URI in the GeneratorModelLinkingService. The proper solution would be an URIConverter implementation, but I want to try the other approach before working more on this one.

balazsgrill commented 11 years ago

Here is the other solution: https://github.com/balazsgrill/EMF-IncQuery/commit/b9d85885f6695ed481346958365237bf959fe246

This allows to load registered packages (with genmodel) from the target platform, without an eiqgen file. As the target platform contains all workspace plugins, this enables to load packages from the workspace without an eiqgen file.

However, if there is an eiqgen file, it can override the selected genmodel.

istvanrath commented 11 years ago

Moved to Eclipse Bugzilla. https://bugs.eclipse.org/bugs/show_bug.cgi?id=398720