[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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