Re: [viatra-dev] [incquery-dev] IncQuery API break (PSystem?)vsIncQuery

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

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,
Zoli
> Cheers
> Gábor
> 
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest 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