Community
Participate
Working Groups
Due to hand coded functionality in the generated classes for the OCL Pivot model, the code generation for QVTOperational MM produces code with compilation errors. This bug is to track the issue and look for the best way to sort this out.
Concerning the ResolveExpImpl it seems that there is an unnecessary (not used even in the own class) public abstract method getReferredFeature at Pivot OCL::CallExpImpl
(In reply to comment #1) CallExpImpl::getReferredFeature has no references and so can be safely deleted. For now just return null or throw an exception just like AssociationCallassCallExp.
(In reply to comment #2) > (In reply to comment #1) > CallExpImpl::getReferredFeature has no references and so can be safely deleted. > May I commit harmless changes to OCL code using QVTo bug issues ? Should I instead open bugzillas for the OCL Project ? Can they also be committed to master (as long as they are harmless and related to examples.*) ? Cheers, Adolfo.
I'd prefer you to commit them to asbh/nnnnnn branches and I'll cherry pick them onto master after review/coordination with my changes.
Pivot CallExpImpl fixed at 257dde5eff9525982635e15680f04d74bb5d3d69 commit ModuleImpl still pending.
The createXXX methods come from the standard MDT/UML2 genmodel technology. AFAIC they are never used, so the simplest solution may be to find the genmodel setting that controls them and switch them off.
Hi Ed, (In reply to comment #6) > The createXXX methods come from the standard MDT/UML2 genmodel technology. AFAIC > they are never used, so the simplest solution may be to find the genmodel > setting that controls them and switch them off. Perhaps, the solution is using the "MDT/UML2 genmodel technology" so that the implementation is correctly generated for ModuleImpl ;) The following methods from DomainPackage need also implementation, currently hand-coded in the Pivot PackageImpl: public EPackage getEPackage() public PackageId getPackageId() Fast solution: copy-paste. However, we know that there other smarter solutions, for instance, that one we have used to provide the accept methods implementation. Cheers, Adolfo.
(In reply to comment #7) > Fast solution: copy-paste. However, we know that there other smarter > solutions, for instance, that one we have used to provide the accept methods > implementation. Yes. Get the right solution manually today. > Perhaps, the solution is using the "MDT/UML2 genmodel technology" so that > the implementation is correctly generated for ModuleImpl ;) Of course. One of my background activities is the UML+OCL to Pivot MM2MM transformation. Currently this goes direct to Pivot.ecore so cuts out all the UML2 complexities. Sure to solve the createXXXX problem too. [Four of my recent bug fixes were to get the UML 2.5 Beta XMI parsing again.]
(In reply to comment #8) > > Yes. Get the right solution manually today. > ?. To me the right solution is not the manual one, but the generated one. Please, specify.
(In reply to comment #9) > (In reply to comment #8) > > > > Yes. Get the right solution manually today. > > > > ?. To me the right solution is not the manual one, but the generated one. Certainly. > Please, specify. But "today" manually is the right solution. The final full automated solution may be months perhaps years away.
> > > Perhaps, the solution is using the "MDT/UML2 genmodel technology" so that > > the implementation is correctly generated for ModuleImpl ;) > > Of course. One of my background activities is the UML+OCL to Pivot MM2MM > transformation. Currently this goes direct to Pivot.ecore so cuts out all the > UML2 complexities. Sure to solve the createXXXX problem too. [Four of my recent > bug fixes were to get the UML 2.5 Beta XMI parsing again.] Meanwhile, I've been trying to use the "MDT/UML2 genmodel technology" to generate proper ModuleImpl for the QVTOperational.ecore MM. However, it's not as easy as saying to the genmodel that it must use the "org.eclipse.uml2.uml.ecore.importer". Would I need a QVTOperational.uml model ? I remember that for OCL we used to work with the UML model, then create the ecore one. I have the impression that I could progress faster with some guidances about how to properly use this "MDT/UML2 genmodel technology"... Any documentation or guidance is welcome.
(In reply to comment #2) > (In reply to comment #1) > CallExpImpl::getReferredFeature has no references and so can be safely > deleted. getReferredFeature is no longer part of the Pivot API so any overloads in QVTo should be @Override errors.
(In reply to comment #12) > (In reply to comment #2) > > (In reply to comment #1) > > CallExpImpl::getReferredFeature has no references and so can be safely > > deleted. > > getReferredFeature is no longer part of the Pivot API so any overloads in > QVTo should be @Override errors. Yes, that was fixed time ago. [I don't know when since I can't access per file GIT history as I did months ago, EGit is really annoying. If you have any trick to do that with recent versions, please, let me know it.]
