Re: [incquery-dev] Eiqgen-based EPackage resolution unnecessary?

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

we have talked this in todays meeting. As the generated_package attribute is often not added, we cannot leave out the genmodel-based resolution. However, we should aim at using the target platform based approach as often as possible, as it works better when the extension point provides the genmodel attribute.

On the other hand, the findMember issue gives a warning for now; and it should be examined whether some better approach exists in the future.

Thanks for the feedback,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.02.19., at 11:19, Ábel Hegedüs <abel.hegedus@xxxxxxxxxx> wrote:

> Hello,
> 
> I agree that it would be nice to use this approach instead of the eiqgen.
> However, the current implementation has the following problems:
> - if the generated_package extension point does not refer to the genmodel,
> only the Package class, the tooling fails completely.
> - if the refered genmodel is outside of the project (e.g. when the model
> project is different from where the genmodel is located),
> IContainer.findMember will only look inside the target project and will
> return null. This causes NPEs, that could be handled better (e.g. by adding
> an exception message that the resource with the given path was not found).
> 
> Since we can access extension points through the target platform, couldn't
> we use the generated Package as an alternative point to find the generated
> code?
> 
> Cheers,
> 
>   Ábel Hegedüs
> 
> Fault Tolerant Systems Research Group
> Department of Measurement and Information Systems
> Budapest University of Technology and Economics
> 
> 
> On 18 February 2013 22:17, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:
> 
>> Hi,
>> 
>> while debugging some EPackage resolution related issues, it dawned on me
>> that the code from Balázs Grill (see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=398720) to open EPackages
>> from the target platform might make the eiqgen-based resolution
>> unnecessary, as the target platform not only includes binary plug-ins (by
>> default from the host), but also all open plug-in projects.
>> 
>> This can be quite important, as this approach is much cleaner than the one
>> we took the eiqgen files. This means, if the target platform approach is
>> truly better, I would like to remove the eiqgen based resolution (it would
>> be cleaner, and also less code to maintain).
>> 
>> However, I wouldn't want to cause some regressions this way. So at the
>> moment I would ask that everybody who uses a recent build from eclipse.org(either CI or integration, and especially those who will use milestone 1),
>> and try to turn off eiqgen based package resolution, and report when it
>> fails.
>> 
>> Alltogether, I am interested in use cases that the eiqgen approach
>> supports, but the target platform based does not, so we could make an
>> informed decision (hopefully in the M2 timeframe).
>> 
>> Thanks,
>> Zoli
>> -- Zoltán Ujhelyi
>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>> 
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>> 
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/incquery-dev
>> 
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/incquery-dev