Community
Participate
Working Groups
Created attachment 169248 [details] fix for import NPE If I include the line "import Library;" at the top of my QVTr file, with Library.qvtr in the same folder, I end up with an NPE out of the parser. The attached patch fixes the problem, but uncovers some more problems: - an NPE in org.eclipse.ocl.lpg.AbstractProblemHandler.handleProblem(). It seems line numbers for errors in the top level qvtr file are being looked up in the imported one's context. Since my imported file is shorter, the index is out of bounds, returns null, boom. - The problem being reported (which triggers that above bug) is that a relation call cannot be found; the one I'm trying to make from my main transform to the imported one. I'm having a hard time figuring out how it's supposed to be done, which may actually get me up and running before that handleProblem() NPE gets fixed. I know this second issue might be more of a newsgroup question, but I figured whoever commits this fix may know the answer.
further investigation shows when the transformation's extend parameter is parsed, the environment fails to find the transformation, despite it already being loaded. On line 72 in org.eclipse.qvt.declarative.parser.qvtrelation.environment.QVTrTransformationEnvironment.QVTrTransformationEnvironment(), env.lookupImportedTransformation() returns null, because env.qvtRegistry is empty; however, when that line is executed, transformationCS.eContainer.transformation does include the transform to be extended. Maybe I'm not initializing my environment properly? XMIResource astResource = (XMIResource)resourceSet.createResource(astURI, QVTRelationPackage.eCONTENT_TYPE); FileHandle fileHandle = getFileHandle(model + ".qvtr"); QVTrFileEnvironment environment = new QVTrFileEnvironment(fileHandle, resourceSet, astResource); environment.setProblemHandler(problemHandler); ICSTRootEnvironment rootEnvironment = environment.parse(null, environment.getFile(), null);
I think you are misunderstanding the "import" statement. QVTr like CompleteOCL has a totally inadequate import capability, leaving it to the '100% compliant' implementation to sort out the mess externally. I now regard this as a language bug for which there is already an OCL issue that I'm resolving. Models should be importable by URI since external URI resolution is a well understood, although diversely resolved, problem. In the meantime, import imports a named model. The mapping from the name to the URI is performed by the QVTd Model Registry, so you need to emulate the entry that you'll find in the RoyalAndLoyal example. -- MDT/OCL is currently making a major editing and consequently parsing transition to exploit Xtext. I am aim to do this for QVTc and QVTr too as part of the revamp to provide a transformation chain execution capability. http://wiki.eclipse.org/M2M/QVT_Declarative_Languages. -- Since QVTd currently has no execution capability, I'd be very interested to know how you're using QVTd (and whether you're interested in contributing to further work.)
(In reply to comment #0) > Created an attachment (id=169248) [details] > fix for import NPE Thanks. Committed to CVS head. This is actually caused by the change to MDT/OCL's Parser, which now delegates rather than derives the LPG parser. The delegates parser is created lazily to allow re-use but fails to create the delegated parser if the first interaction is getIPrsStream rather than reset. Adolfo: Should getIPrsStream do a null test and a reset(getILexStream()) to avoid a null return? > - an NPE in org.eclipse.ocl.lpg.AbstractProblemHandler.handleProblem(). It > seems line numbers for errors in the top level qvtr file are being looked up in > the imported one's context. Reproducible almost out of the box by introducing an error into the imported file from the ModelMorf Import example. > > - The problem being reported (which triggers that above bug) is that a relation > call cannot be found; Reproducible out of the box with the ModelMorf Import example. (In reply to comment #2) My confusion; import/include QVTr content, and import/include meta-models are both but differently inadequate.
Comment on attachment 169248 [details] fix for import NPE Marking the patch checkbox, to see if I can check the patch via web (I don't have a fresh QVTr installation right now).
Created attachment 169320 [details] Better QVTrLexer initialization Ed, The problem comes from not using the proper QVTrLexer constructor. The proposed patch gives a (better, IMO) alternative way to initialize the lexer. When creating the QVTrLexer the LexStream should have been initialized. This doesn't occurs when using a unique Environment as parameter of the constructor. I already tried to remove this constructor see the point 7 in https://bugs.eclipse.org/bugs/show_bug.cgi?id=242153#c44 . I'm not sure why it finally remained there. Maybe because of backwards compatibility reasons, or who knows... > Adolfo: Should getIPrsStream do a null test and a reset(getILexStream()) to > avoid a null return? I think it's not a foolishness. However, I don't like to gratuitously or unnecessarily change the templates. It makes more sense creates a lexer based on a given input. Cheers, Adolfo.
The QVT projects have moved to using Xtext rather than LPG, so LPG-related problems are obsolete.
CLOSED after more than a year in RESOLVED state
