[
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,
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