Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] incquery & xcore demo for eclipsecon
Ed,

many thanks for your insights. We'll look into this approach.

Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

On Tuesday, October 22, 2013 at 10:52 AM, Ed Merks wrote:

Istvan,

EMF's generator now uses org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.mergePluginXML(String, String, String) for merging and does so using regular _expression_ matching.   Given we now have a release that uses these patterns, we can't simply eliminate them. Ideally your generator extensions would simply produce the necessary textual plugin.xml and merge it.  The first argument of the mere method you might use a key different from the one EMF is using for the extensions you have that are different from the EMF ones, so in that case you could generate a plugin.xml with just your extensions with keys different from EMFs keys and then merging will add your new stuff and support merging for them should you need to regenerate changes to them.

Regards,
Ed


On Thu, Oct 17, 2013 at 10:00 AM, Istvan Rath <rath@xxxxxxxxxx> wrote:
Hi Ed,

I might have sent the previous message to the wrong address.

Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

Forwarded message:

From: Istvan Rath <rath@xxxxxxxxxx>
To: Ed Merks <merks@xxxxxxxxx>
Cc: Tamas Szabo <tamas.szabo@xxxxxxxxx>, Ujhelyi Zoltan <ujhelyiz@xxxxxxxxxx>
Date: Wednesday, October 16, 2013 2:28:02 PM
Subject: Re: incquery & xcore demo for eclipsecon

Hi Ed,

Thanks again for your help. The good news is that we've managed to get IncQuery working with Xtext 2.5. It seems that a working setup for the Xcore-IncQuery integration can be achieved by starting from Kepler and using the milestone update sites for EMF, Xcore and Xtext. As a side note, it will also work on Luna nightly with one catch that is being addressed at the moment (a weird PDE bug, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=419431 for details).

However, there is one more issue remaining about which I would like to ask your opinion. It seems that the combination of the IncQuery and Xcore builders can get into a weird inconsistent state due to the way the plugin.xml is being manipulated.

As Tamas put it:
Regarding the @Ecore annotation (in xcoreiq) and its effect for
rewriting the plugin.xml with the new nsUri;
- for the first time a <!-- @generated library --> comment is placed
into the plugin.xml for the generated package entry.
- this will be removed during the IncQuery generator phase
- from this point the xcore generator is unable to update the entry with
the new nsUri because it is looking for this comment.

Our builder manipulates the plugin.xml with PDE facilities, and we haven't yet found a way to preserve comment blocks.

So, the question is:
- do you know of some reasonably simple way to manipulate the plugin.xml and correctly preserve the comment blocks? 
- or, alternatively, do you think it would be feasible to change the Xcore builder to use e.g. the extension id instead of the comment block to locate the part that it needs to update?

regards
Istvan


--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

On Wednesday, October 9, 2013 at 10:17 AM, Ed Merks wrote:

Istvan,

No, an update to Xcore 1.2.0 will require EMF 2.10.0 and (apparently) Xtext 2.5.0.  The only way to avoid that is to build Xcore 1.2.0 yourself from git, then you can install EMF 2.10.0 and Xtext 2.4.3...

Better for the users/clients who wish to try this themselves is if there are builds available for all the necessary things, with the "IncQuery doesn't work with Xtext 2.5" issue seeming to be the major roadblock...

Regards,
Ed


On 09/10/2013 10:07 AM, Istvan Rath wrote:
Hi Ed,

to put it in more simple terms:

- is there a way to run an "up-to-date" (i.e. including Tamas' patches) version of Xcore and EMF in Kepler with Xtext-2.4?
- or we have to somehow make sure that IncQuery (and all the rest of the stuff) runs in Luna with Xtext-2.5?

best regards,
Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

On Wednesday, October 9, 2013 at 9:47 AM, Tamas Szabo wrote:

Hi Ed,

We are trying to figure out what would be the simplest solution to
create the environment for the demo about the IncQuery & Xcore
integration project.
- The current release from EMF and Xcore (the ones available in Eclipse
Kepler update site) doesn't contain the patches that we have applied
through Gerrit.
- I have tried to install the latest milestone (2.10.x plugins) from
this update site:
during the installation it tries to install the Xtext 2.5.0 plugins too.
This is a problem, because at the moment IncQuery is not fully
compatible with this version (and due to this neither with Eclipse Luna).
- On the other hand if I have the 3 distinguished plugins from git
master in my workspace (org.eclipse.emf.ecore,
org.eclipse.emf.ecore.xcore, org.eclipse.emf.ecore.xcore.lib - these are
affected by the patch) with Xtext 2.4.3 everything works fine.

Do you have any idea what would be the most convenient way to install
the requirements? It doesn't look really nice if people need to get some
plugins from the git, some other from update site to make this whole
thing work. We try to figure out something till Eclipsecon, could you
please help us?

Kind regards,
Tamas






Back to the top