Also note that if you develop EMF-IncQuery from source, you should regenerate the model code from rete-recipes.genmodel.
Hi,On 2015. ápr. 21., at 14:20, Bergmann Gábor <bergmann@xxxxxxxxxx> wrote:
Hi,
BTW, interesting observation: the ecore tests do pass on Jenkins, but > not on Hudson. However, the school tests work fine on Hudson. So I am > assuming Hudson uses pregenerated code for the ecore tests, while code > is generated on the fly in all other cases? Weird.
Sorry, but I don’t understand this. Are the school tests executing on Hudson?
Yup, I mixed them up again.
So, Ecore tests fail on Jenkins, but School tests do not fail on Jenkins. The tests that are do run on Hudson run seemingly fine.
What's the difference between the way the Ecore and School test suites are treated on Jenkins?
The school case generates its pattern matcher code, while generated pattern matcher code is shared through the repository. Now it could be generated, but it was not updated.How much work is this? If one hour or two, I guess, it is worth it.
OK, done.
Thanks; the implementation seems a bit “strange”, e.g. the constructor returns a different, seemingly unrelated type. However, it seems to work, so it is already much better.Cheers,ZoliCheers
Gábor
-- Zoltán Ujhelyihttps://www.inf.mit.bme.hu/en/members/ujhelyizFault Tolerant Systems Research GroupBudapest University of Technology and Economics
-----Original Message----- From: Ujhelyi Zoltán
Sent: Tuesday, April 21, 2015 11:16 AM
To: Incquery developer discussions
Cc: Viatra project developer discussions
Subject: Re: [viatra-dev] [incquery-dev] IncQuery API break (PSystem?)vsIncQuery MavenCompiler
Hi,
answers inline
On 2015. ápr. 21., at 11:09, Bergmann Gábor <bergmann@xxxxxxxxxx> wrote:
Hi,
replacing the TypeUnary/TypeBinary classes with the TypeConstraint class breaks _every_ generated pattern matcher code available
True. Is it not OK to require the users to clean & build their projects after an upgrade to 1.0?
I am not _completely_ against it, if it is unreasonably expensive to provide a better way. However, I feel we have more and more users, and we can alienate them with incompatible updates, so we should aim to minimize the costs if possible.
If we think this is a problem, we can of course create completely fake TypeUnary etc. classes at the original package location that just instantiate TypeConstraint in their constructors; we can also add an Object field CONTEXT back to the superclass of generated query specifications; all that to trick the old generated code into compiling and working correctly even before it is first regenerated. Should I do this?
How much work is this? If one hour or two, I guess, it is worth it. If much more, then we should discuss it this afternoon.
BTW, interesting observation: the ecore tests do pass on Jenkins, but not on Hudson. However, the school tests work fine on Hudson. So I am assuming Hudson uses pregenerated code for the ecore tests, while code is generated on the fly in all other cases? Weird.
Sorry, but I don’t understand this. Are the school tests executing on Hudson?
Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
_______________________________________________
viatra-dev mailing list
viatra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/viatra-dev
_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incquery-dev
_______________________________________________incquery-dev mailing listincquery-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/incquery-dev
|
