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

[Bergmann Gábor <bergmann@xxxxxxxxxx>]

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?

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?

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.

Cheers,
Gábor


-----Original Message----- 
From: Ujhelyi Zoltán
Sent: Monday, April 20, 2015 8:26 PM
To: Incquery developer discussions
Cc: Viatra project developer discussions
Subject: Re: [viatra-dev] [incquery-dev] IncQuery API break (PSystem?) 
vsIncQuery MavenCompiler

Hi,

sorry for entering the discussion late, but I have some issues with this 
kind of API change: replacing the TypeUnary/TypeBinary classes with the 
TypeConstraint class breaks _every_ generated pattern matcher code 
available. Are we comfortable with that? How much effort would be to keep a 
TypeUnary/TypeBinary that works similar to the new TypeConstraint class, 
while it is deprecated?

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

> On 2015. ápr. 20., at 16:27, David, Istvan <davidi@xxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Okay, now it makes sense. And the VIATRA master job is back to normal, so 
> thanks, guys.
>
> Cheers,
> Istvan
>
> 2015-04-20 14:42 GMT+02:00 Ábel Hegedüs <abel.hegedus@xxxxxxxxxx>:
> Hi!
>
> Yes, it seems you have simply copied the incquery-master job which has all 
> sort of dangerous setting enabled (such as deploying to repo.eclipse.org 
> and downloads.eclipse.org). Fortunately, you only ran a "ci" build, so the 
> downloads are not affected and hopefully only a SNAPSHOT version was 
> pushed to repo.eclipse.org.
> I have changed you job a bit to avoid this (by removing a script, changing 
> to private repository and clean install on the runtime maven task) and 
> started a master build to overwrite the version in repo.eclipse.org.
>
> Cheers,
>   Ábel
> > On 2015.04.20. 14:22:19, Bergmann Gábor <bergmann@xxxxxxxxxx> wrote:
> >
> > Hi!
> >
> > The upcoming API is maintained on the branch api-refactor1.0, and will 
> > hopefuolly be merged into master today, just in time for the milestone.
> > For verification, I have built this branch on Eclipse’s Hudson server, 
> > where it was compiled and tested.
> > So there may be some maven caching magic that might cause this branched 
> > version of the maven compiler to run instead of the master version.
> >
> > Cheers,
> > Gábor
> >
> >
> > From: David, Istvan
> > Sent: Monday, April 20, 2015 2:01 PM
> > To: Incquery developer discussions ; Viatra project developer discussions
> > Subject: [viatra-dev] IncQuery API break (PSystem?) vs IncQuery 
> > MavenCompiler
> >
> > Hi guys,
> >
> > We encountered an issue with the latest VIATRA build in the CEP module's 
> > core plugin, which uses the IQ Maven Compiler. I'm 99% sure it's some 
> > IncQuery versioning issue.
> >
> > It's related to the PSystem (I guess) and it only affects the generated 
> > *QuerySpecification classes. Details below.
> >
> > Typical errors:
> > [ERROR] import 
> > org.eclipse.incquery.runtime.emf.types.EClassTransitiveInstancesKey
> > [ERROR] import 
> > org.eclipse.incquery.runtime.emf.types.EStructuralFeatureInstancesKey;
> > ...
> > [ERROR] new TypeConstraint(body, new FlatTuple(var_transition), new 
> > EClassTransitiveInstancesKey((EClass)getClassifierLiteral("automaton.meta", 
> > "TypedTransition")));
> >
> > The latest line's counterpart in my working copy:
> > new TypeUnary(body, var_transition, 
> > getClassifierLiteral("automaton.meta", "TypedTransition"), 
> > "automaton.meta/TypedTransition");
> >
> > Could you give us a hint please? Thanks!
> >
> > Cheers,
> > Istvan
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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

_______________________________________________
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