Community
Participate
Working Groups
Created attachment 104037 [details] Plug-ins Attached comprises all QVT Declarative models from GMT/UMLX repackaged as one plug-in per model. Ecore-based edit/editor plug-ins are available. EMOF-based edit/editor plug-ins are not since they contribute nothing. This submission is a companion to the revised attachment to bug 234220 which includes an org.eclipse.qvt with the Rose models. This submission is also a companion to a volley of OMG issues that will detail incompatibilities with the OMG 07-07-08 models.
Ed, thank you! Since attached QVT Operational models depend on Declarative part we'll wait for counterpart to appear in CVS. Also I note that manifests declare Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Do you really need 1.6 compatibiltiy? Isn't JavaSE-1.5 enough for the patch?
1.5 is certainly ok. 1.6 seems to have a major trivial bug-fix with regard to interpretation of @Override, which has caught me out occasionally. The 1.5/1.6 decision should be uniform across M2M QVT. I kind of assumed that post-Ganymede 1.6 was standard enough to mandate it. You probably don't like the 0.7.0.qualifier version either. Perhaps the plug-in ids are bad too.. Perhaps the provider/copyrights should be eclipse.org not E.D.Willink with some hints of A.Sanchez and Open Canarias. All good trivia to resolve.
Hi Sergey, Could you confirm me that the package names will be those included in the zip file? In that case, I could start refactoring all my work which depends on those metamodels. About the hints Company: Open Canarias S.L. Name: Adolfo Sánchez-Barbudo Herrera, which could be shorten as A. Sanchez-Barbudo By the way, are you or any colleague going to OMG's symposium. Open Canarias has contributions to do to QVT-OML project in several ways when these OMG compliant metamodels are adopted. Regards, Adolfo.
Hi Adolfo, I confirm that plug-ins from patch (org.eclipse.m2m.qvt.oml.ecore.* and org.eclipse.m2m.qvt.oml.emof.*) will be contributed without name changing. After Ganymede release we can consider these naming and probably rename plug-ins namespace to 'org.eclipse.qvtoml' or something like. Unfortunately none of our team won't attend OMG's symposium. It'll be great if you can point areas in QVT-OML project you are going to contribute to. I understand that it's IP field so I'm not going to pump details about your plans ;) Regards, Sergey
(In reply to comment #3) Adolfo, just a note on your dependency to those metamodels. It would be only by CVS access to sources as long as org.eclipse.qvt.declarative (a dependency of the contributed metamodels) has no releng created. I guess, it's how you use it anyway so far, but unfortunately the same applies to all other things in qvt.oml that would make use of it. The reason is that I do not see a way how to include it in qvt.oml builds.
Adding Quentin Glineur... See comment #5 With QVT-OML about to develop a dependency on QVT-Declarative, it seems almost top priority for at least part of QVT-Declarative to join the well-releng'ed group of projects. This seems like the first of many possible project conflicts that may arise because of the more mature state of QVT-OML than QVT-Declarative. Is it worth revisiting the idea of a QVT-Infrastructure project to eliminate the QVT-OML to QVT-Declarative dependency?
(In reply to comment #6) Ed, I'm not sure that moving it to any other place without releng would solve the problem of such QVT-OML dependency. I think, if both QVT-OML and QVT-Declarative provide 'QVT-xxx metamodels' features, it should be fine for all consumers interested in metamodels only. I'm not against the QVT-Infrastructure idea in general but for now, I think we do not have sufficient arguments for to its creation yet. Let's see in the future.
No problem. Just raising the possibility. Next year QVT-Declarative will hopefully be in a sound state too. Splitting off a QVT-Infrastructure once the models are in place seems unlikely to happen.
Hi, I agree with Radeck and the 'QVT-xxx metamodels' features seems wise. Once the submission is accepted, I can make a quick build that QVT OM will be able to refer in their releng. I don't feel there is a strong need for a heavy releng mechanism from Declarative QVT *right now*. Is there ? Regards, Quentin
Hi Sergey, Radek That's a pity. I would have liked to show you some technical details. I suppose that you are planning future work for the next release. So I think that it's a good moment to explain the actual state of our work. As you know, I have been working on a parser/editor for the QVTo language. Exploiting MDT-OCL 1.2 and UMLX projects, I have developed a parser which covers nearly 100% of the QVTo language. Our original idea was contributing the QVTo parser to UMLX project. However since most of the functionality will be moved into the declarative project, and specially there is another official project related to QVTo, it seems more appropriate to make contributions that may help the qvt.oml project achieve fuller functionality. Some interesting features of our parser: - We generate models 100% compliant to the QVTo specification (models conform to those Ecore-based QVTo metamodels). - All the abstract syntax of the language is supported (QVToperational and ImperativeOCL). - MDT-OCL partitioning into Analyzer and Parser exploited - 42 test cases, which cover different aspects of the specification (just one test case related to the stdlib and the new QVTo types don't pass, yet ;)). - After correcting some mistakes, examples from QVTo specification (book2publication, Encapsulation, UML2Rdms, spemprofile2metamodel) are covered. - Detection of ambiguous names is resolved. - Supporting multiple modules definition (intra-file extension of modules is resolved). - Supporting metamodels definition. - EValidator for QVTo models is in progress, and it's integrated in the parser/editor. - A prototype of the QVTo Stdlib is modelled, and integrated in the parsing process (via OCLStandardLibrary interface ). Despite the specification not being very clear what the Stdlid should look like, IMO it's a prototype very close to the specification. - In principle, all the shorthands related in the specification are supported. Unresolved features: - Proper extension of the OCL type checking system (bug 233673). - Inter-file resolution (imports to other transformations/libraries defined outside the file). - Minor aspects about metamodels definition need completion. Editor is very simple: - Just error markers, and syntax colouring. A merge of Borland and Open Canarias work would be interesting for both, and of course, for the Eclipse community: - qvt.oml would gain quality with the features mentioned above. - we would be very interested in using the Borland's QVTo editor, if it at least generated QVTo models compliant to the OMG's specification. Ways of contribution: - ideally the qvt.oml execution infrastructure, and qvt.oml editor, would be able to exploit this complete qvto parser. However, I suppose that using all our work will not be easy for your team, so I have considered some alternatives: - EValidator for the OMG-compliant QVTo Metamodel. Although it is not completed, I'm working on it. - Contributing our test cases, so all the stuff which is not working well in qvt.oml project can be analysed, implemented or corrected. - Because the qvto grammar just depends on LPG and EssentianOCL, all the missing rules can be contributed (at least the production rules). - I have considerable knowledge about QVTo specification and processes involving a parser. I could try to contribute a list of failures in your current implementation. - Contributing all the code, so you have an alternative implementation which can help/lead your future work. I have studied the possibility of contributing the code in bugzilla, but previously some patches related to OCL need to be solved, and some dependencies on UMLX project need to be sorted out. And of course we would like to know your point of view, future plans, etc. Cheers, Adolfo.
Created attachment 104976 [details] RC4 Update This update is a companion to the RC4 update to bug 234220. The models are regenerated using RC4, fixing bug 235797. The tests folder contains new contributions; the JUnit tests that produce the Compliance.html statements and the OMG Issues.
(In reply to comment #10) Hi Adolfo and Ed! Just in case, does your implementation or any other product execute the QVTO AST you create? Cheers, Alex.
Hi Alex, I think that Radek can tell you something about our approach, because we showed it to him at EclipseCon. Anyway, yes, we have an own approach to execute that QVTo models, however we don't cover all the QVTo language yet. We have an already executable low-level transformation language (an emf-based metamodel called ATC which describe the basic primitives related to transformation concepts). With a model transformation, we transform QVTo models into ATC models, which are finally executed. Although we have several executable QVTo transformations, the QVTo2ATC transformation is not finished yet. Victor Sanchez may answer you with more detailed and up-to date information about its current state. However, because of this transformation is not yet finished, and the ATC language is not published yet, our primary goal is contributing just the parser which I think it's quite mature. Although I'm still refining it ;). Cheers, Adolfo.
(In reply to comment #13) Hi all!!! Yes, Alex is right in thinking that our motivation must go beyond the mere producing a precise formal model out from parsing QVTo text. Our company would not be able to afford such a waste of resources. Concerning ATC, it is a dynamically-typed imperative byte-code model transformation language built on top of EMF. It relies on Java for common operational constructs and on the EMF API to implement instructions specific to model transformations. The funny thing about ATC is that the engine only handles models, that is, parsing involves only the XMI format. Funny in the idea of simplicity ;) Since we participate in the Eclipse/OMG Symposium, which has to do with open (source) implementations, it is my goal to have ATC published during this week. The first approach to supporting QVTo was somehow similar to what I understand is the current Borland solution. The parsing stage didn't involve generating ASTs. Instead it directly generated equivalent executable ATC models. Later on we decided to split the process in two stages, and it has really paid off. Now Adolfo parses to QVTo models, and I translate them into ATC via a model transformation. This transformation will also be published along with the language. I drag behind Adolfo's editor capabilities, and lack of time makes progress not as fast as I'd like. Nevertheless, currently OCL2ATC covers almost all the EssentialOCL and a great deal of the OCLStdLib. QVTo may be now at a 60-70%, it is difficult to give a figure out of nowhere. Trace instances are implemented. IIRC, they lack correct support to multivalued parameters (work in progress), and they are based on a unique QVT trace metamodel. Otherwise, a metamodel per transformation must be handled, a fairly complex situation to handle in practice, and also unacceptable (and avoidable) from my point of view. Transformations to translate generated trace models to other formats may be provided. Cheers! Victor
(In reply to comment #10) Sounds great Adolfo, looking forward to look into that after Ganymede. In general, I agree with anything that would improve the QVTo quality, spec compliancy etc. and all that the Eclipse community is supposed to get. We will setup a plan soon how to move on things in this direction. I'm also interested in your test cases and the list of failures of our current impl, (surely I know there may be many ;-)) It would be also helpful if you could contribute your work or publish it in some way, even though there are unresolved references etc. Just to get a better overview of where you are, so along with the knowledge of where we are ;), we could do a better planning and figure out how to best merge our efforts.
Hi Radek, Sorry for the delay, I have been busy preparing the trip to Ottawa, the return journey, etc. I think that the faster and easier thing that I could do right now, is providing the examples which I'm using to test the parser. I'll check them again, and I'll attach them to the bugzilla. Should I create a new bugzilla for this ? What about if you point me out to any kind of .qvto examples which you are managing, to check if the parser behaves as it is expected ? ;). Cheers, Adolfo.
Committed.
Created attachment 111899 [details] Bureaucratic updates The attached patch for the recent CVS commit fixes a variety of bureaucratic details that appeared while working with the QVT DEclarative equivalent... No changes to models or to any Java code. 4 missing about.html added and build.properties changed accordingly. 4 existing about.html tweaked to match official Eclipse template. .qualifier added to plugin versions; you may want to change the "0.7.0". Project specific Java settings eliminated. Minimum JRE changed from J2SE-1.6 to J2SE-1.5 and classpath set accordingly. 3 missing plugin.properties added for test plugins. org.eclipse.m2m.qvt.oml.test.emof.all/.cvsignore added to ignore temp folder of test results [org.eclipse.qvt.declarative.test.all has been refactored to create the class in org.eclipse.qvt.declarative.test.emof.all referenced by org.eclipse.m2m.qvt.oml.test.emof.all]
Created attachment 111900 [details] QVTOML Models Feature Contribution The QVT Declarative features have been refactored to support the attached org.eclipse.m2m.qvtoml.ecore.qvtoperational.feature. This may be helpful in providing the redistribution of the QVT Declarative Model plugins and OCL Edit plugins within QVTOML. [This feature appears to produce the required deplayable features and plugins, but the resulting deployment has not been tested.]
As part of the move of GMT from Technology to Modeling, is there anythingfor Webmaster to do here? -M.
Nothing needed at the GMT/UMLX end. ? help with improved releng at the QMT OML end ?
Nothing todo for Webmaster on the QVTO side either. I'll just apply patch and add new plugin later today.
Patch from comment #18 applied. Feature from comment #19 was renamed to 'org.eclipse.m2m.qvt.oml.ecore.qvtoperational-feature' to match existing name-template and committed.
