Community
Participate
Working Groups
UML 2.5 changed clientDependency to derived; it is therefore no changeable and ATL transformations that assign it bomb. This only starts to show up now that trsts for the KDMtoUML functionality are no longer ignored. Although UML2Copy.atl is auto-generated a rehex easily fixes the 300 copies of clientDependency. Then we get an NPE on UML::ExecutionEvent which is not present in UML 2.5. Elimnating the associated ATL copy rule we fall over the missing UML::CreationEvent Clearly the MoDisco UML support is seriously out of date and incompatible with Eclipse UML2. The problem UML2Copy.atl is commented as generated by EModelCopyGenerator.atl, but there appears to be no UI for it and no build rules either. Once UML2Copy.atl is regenerated, maybe things will just work. Until then is it honest to even offer UML functionality that is so suspect?
New Gerrit change created: https://git.eclipse.org/r/155758
Gerrit change https://git.eclipse.org/r/155758 was merged to [master]. Commit: http://git.eclipse.org/c/modisco/org.eclipse.modisco.git/commit/?id=da3874beb41823239a7adba394e4b80eb4eb0b23
For 1.5.1M1 we can just exclude org.eclipse.modisco.usecase.modelfilter.tests from pom.xml. Strangely these tests are not part of the interactove launch.
Hi Ed, I have not been able to find the referenced EModelCopyGenerator.atl transformation neither. However, there is this similar transformation (working on the ATL EMFTVM) doing the same work and actually tested on the UML metamodel: from any metamodel XXX in Ecore, it produces a corresponding XXXCopy transformation in ATL for copying corresponding models. https://github.com/atlanmod/Ecore2ATLCopier Do you think it could make the job? In parallel, Fabien Giquel is also studying the possibility of a Java version of this feature.
So far I have attempted mindless update to UML2 5.x. Easiest was fixing the nsURI registration that caused the empty stack exception. Pretty easy was load and save of UML test models to eliminate 'clientDependency'. Removing same from *.atl via a regex wasn't that hard either and once an ATL nature was added the ASM rebuilt. I also fixed some *.atl for packageableElement ... But clearly this is not enough. I eliminated ExecutionEvent, but then once CreationEvent showed up I knew I was onto a loser, since UML2Copy references every single obsolete metamodel element. -------- Unfortunately since ATL is weakly/un-typed, bugs in ATL transformations do not show up in the editor, so good test coverage is essential to locate them at run-time. A thoughtful update to UML 5.x is necessary, that will address all relevant issues and have test that cover them. UML2Copy is perhaps the most obvious because it enforces an incompatible metamodel. But what does it do? EcoreUtil.copy is certainly much easier. The only rationale I can see is that a good way to implement a nearly-copy Tx is to refine a mindless copy Tx for the irregularities. A Java equivalent won't work for this use case. Why are there no build procedures for UML2Copy (both versions)? In many places there are external builders. but not for UML2Copy. Perhaps there was something in EMF Facet Releng. -------- What is absolutely clear is that the MoDisco UML2 functionality has been broken since Bug 423935 on 2013-12-12 and so presumably since June 2013 (Kepler) but that is a UML 4.x so the probable start of the Bug is June 2012 (Juno) and the nsURI change for UML2 2.4 support in 4.0.0. In my view, life support preserves the prevailing functionality as best it can. It does not need to do work that the developers sidelined for seven years. The choice for me is therefore: - do nothing as in 1.5.0 - leave users to fall over the instant stack exception failure - mindless fixes not yet released as 1.5.1M1 - has a deceptive level of ok till not ok - amputate - remove all UML2 functionality since it cannot be used (While amputating UML2 perhaps the dead BIRT too should be amputated.) -------- Today, on M1 +3 day, I'm inclined to withhold the 1.5.1M1 contribution and stick with 1.5.0. 'Tomorrow', I'm inclined to start amputating, unless some community support is forthcoming.
(In reply to Ed Willink from comment #5) > UML2Copy is perhaps the most obvious because it enforces an incompatible > metamodel. But what does it do? EcoreUtil.copy is certainly much easier. The > only rationale I can see is that a good way to implement a nearly-copy Tx is > to refine a mindless copy Tx for the irregularities. A Java equivalent won't > work for this use case. > > Why are there no build procedures for UML2Copy (both versions)? In many > places there are external builders. but not for UML2Copy. Perhaps there was > something in EMF Facet Releng. > I see that UML2Copy.atl is only used in relationship with BidirectionalAssociation.atl. The purpose of this couple of transformation is that two unidirectional associations become one bidirectional association. The copy of uml is not really needed. I began to write a Java direct refinement on uml resource resulting from kdm->uml, to get rid of UML2Copy.atl/BidirectionalAssociation.atl files. > In my view, life support preserves the prevailing functionality as best it > can. It does not need to do work that the developers sidelined for seven > years. > > -------- > > Today, on M1 +3 day, I'm inclined to withhold the 1.5.1M1 contribution and > stick with 1.5.0. > > 'Tomorrow', I'm inclined to start amputating, unless some community support > is forthcoming. I agree with these observations and conclusion.
(In reply to Ed Willink from comment #5) > 'Tomorrow', I'm inclined to start amputating, unless some community support > is forthcoming. Mindless amputation is not so easy... Obviously all org.eclipse.uml2... dependencies go together with most of their callers and most subroutines/plugins with "uml" in their name, but eventually cutting back hits a grey area. Is the functionality purely UML, or just sometimes UML, in which case control flow revision may be necessary? This is harder for BIRT where there appears to be code that supports a general chart generation tailored/followed by BIRT-specific chart generation; presumably the general chart should stay.
(In reply to Ed Willink from comment #7) > but eventually cutting back hits a grey area I'm beginning to think that the hazards of a mindless amputation are greater than those of a mindless UML 2.5 upgrade; at least we have one huge example that currently fails.
(In reply to Hugo Bruneliere from comment #4) > https://github.com/atlanmod/Ecore2ATLCopier It comes complete with a launch for UML.ecore, so UMLCopier is almost out of the box UMLCopier - 6994 lines, single space indentation UML2Copy - 4156 lines, four space indentation UML2Copy: rule Model { from s : UML2!"uml::Model" (thisModule.inElements->includes(s)) to t : UML2!"uml::Model" mapsTo s ( name <- s.name->debug('Model'), visibility <- s.visibility, viewpoint <- s.viewpoint, eAnnotations <- s.eAnnotations, ownedComment <- s.ownedComment, clientDependency <- s.clientDependency, nameExpression <- s.nameExpression, elementImport <- s.elementImport, packageImport <- s.packageImport, ownedRule <- s.ownedRule, templateParameter <- s.templateParameter, templateBinding <- s.templateBinding, ownedTemplateSignature <- s.ownedTemplateSignature, packageMerge <- s.packageMerge, packagedElement <- s.packagedElement, profileApplication <- s.profileApplication) } UMLCopier: rule CopyModel { from s : MM!Model ( s.oclIsTypeOf(MM!Model) ) to t : MM!Model ( ownedElement <- s.ownedElement, owner <- s.owner, ownedComment <- s.ownedComment, ownedType <- s.ownedType, packageMerge <- s.packageMerge, packagedElement <- s.packagedElement, nestedPackage <- s.nestedPackage, nestingPackage <- s.nestingPackage, profileApplication <- s.profileApplication, name <- s.name, visibility <- s.visibility, qualifiedName <- s.qualifiedName, clientDependency <- s.clientDependency, namespace <- s.namespace, nameExpression <- s.nameExpression, elementImport <- s.elementImport, packageImport <- s.packageImport, ownedRule <- s.ownedRule, member <- s.member, importedMember <- s.importedMember, ownedMember <- s.ownedMember, templateBinding <- s.templateBinding, ownedTemplateSignature <- s.ownedTemplateSignature, owningTemplateParameter <- s.owningTemplateParameter, templateParameter <- s.templateParameter, viewpoint <- s.viewpoint ) } Clearly not the same and both have packagedElement! The new Ecore2ATLCopier looks like an academic exercise for the student - an impressive volume of output is auto-generated, but nothing actually validates whether it is useful. The GitHub history shows that it was a one day wonder - all six *.atl commits on2 Feb 2017 using http://www.eclipse.org/uml2/3.0.0/UML even though it was obsoleted four years ago. Chnaging it to http://www.eclipse.org/uml2/5.0.0/UML makes surprisingly little difference. It would appear that the sole utility of Ecore2ATLCopier is to provide a 114 starter for development of an accurate Ecore-dricen ATL copier. Avoids the need to start with a clean sheet of paper.
The ATL GIT has two different UML2Copy.atl files, one of which is similar, but not identical to one of thetwo MoDisco UML2Copy.atl. (In reply to Hugo Bruneliere from comment #4) > https://github.com/atlanmod/Ecore2ATLCopier THis is a 2017 red herring. The true Ecore2ATLCopier.atl is from 2010, Google-able at: http://soft.vub.ac.be/svn-pub/UML2CaseStudies/uml2cs-transformations/transformations-offline/EModelMergeGenerator.atl It starts: -- @atlcompiler atl2006 -- $Id: EModelCopyGenerator.atl 7948 2010-01-31 11:48:43Z dwagelaa $ -- Generates an ATL transformation that copies models using the given Ecore meta-model query EModelMergeGenerator = ECORE!EClass.allInstancesFrom('IN')->iterate(e; acc : String = '-- @atlcompiler atl2006\n' + '-- Generated by: $Id: EModelCopyGenerator.atl 7948 2010-01-31 11:48:43Z dwagelaa $\n' + But is actually only a library; it lacks the top level module/metamodel declarations. which matches the preamble of the MoDisco UML2Copy.atl.
(In reply to Ed Willink from comment #8) > > I'm beginning to think that the hazards of a mindless amputation are greater > than those of a mindless UML 2.5 upgrade; at least we have one huge example > that currently fails. Hi, If UML amputation is no more the immediate solution, i may push to gerrit my fix specific to component org.eclipse.modisco.usecase.simpletransformationschain : get rid of "UML2Copy.atl/BidirectionalAssociation.atl" files, replaced by a simple uml refinement written in Java. It allows : - make work again the both discoverers "Discover UML model with bidirectional associations from Java project", and "Discover bidirectional associations from UML model", at least for simple interactive cases in my workpsace. - and so reactivate the "SimpleBlackBoxDiscovery" junit test in pom.xml. Ed tell me if you are ok, OR if you think to go on UML features amputation.
Please push the fix. I am increasingly reluctant to go with amputation since I lack the understanding of the code to accurately identify exactly where to amputate. If you push wrt to master you will pick up the EMFFormatter clone that reactivates model content testing abandoned when EMF Compare AI changed.
(In reply to Ed Willink from comment #10) > But is actually only a library; it lacks the top level module/metamodel > declarations. which matches the preamble of the MoDisco UML2Copy.atl. After emailing Dennis Wagelaar, he provides https://github.com/dwagelaar/Ecore2Copier which looks much more promising. In particular the UMLCopier launch uses UML2 5.0.0. AND it excludes derived, transient, not changeable features.
(In reply to Ed Willink from comment #13) > which looks much more promising. It uses EMFTVM's @extends to avoid duplication; result is a 50% line count saving. But examining Component::packagedElement which is less complicated than Package::packagedElement. UML 2.5 defines it as a [0..*] containment. UML2 5.0.0's UML.ecore has Component::packagedElement, but the Java has Component.getPackagedElements() rather than the regular getPackagedElement() demonstrating that UML2's genmodel facility to provide more helpful names has clicked in. This has given me many problems from an OCL perspective as a result of which UML.ecore now has a number of originalName EAnnotations to un-Bowdlerize the spellings for use by embedded Ecore functionality such as OCLinEcore that has not been translated to Bowdlerized names. Since "Cannot set feature uml!Model.packagedElement to value" lies at the heart of the residue of Bug 559016, I have a suspicion that the problem may be a packageElement/packageElements confusion. However a superficial glance suggests UML2 is ok, perhaps ATL is searching for packageElement in a stupid way.
(In reply to Ed Willink from comment #14) > Since "Cannot set feature uml!Model.packagedElement to value" lies at the > heart of the residue of Bug 559016, This is actually a straightforward bug in KDM2UML.atl, moved to Bug 559506.
New Gerrit change created: https://git.eclipse.org/r/156518
(In reply to Eclipse Genie from comment #16) > New Gerrit change created: https://git.eclipse.org/r/156518 Ed, i have a gerrit pb with my last commit : I had a first CI Bot failure (1 junit), and then made some fix and amend to the same commit. Thus last triggered CI build was in success. But however the Gerrit portal still does not show the "+1 Verified CI Bot". Now I don't know how to get the "+1 CI Bot" for effectively pushing to master.
I am afraid that I am no Gerrit expert. Quite the contrary, I find the perverse UI just about guaranteed to ensure I make a mess. Looking at the Gerrit, it appears that both you and the Bot have +1'd, but a +2 is necessary. I also see "Change 156518 - Needs Code-Review Label" below the EF at top left. No idea what it means, may be you used blank text by mistake. Looking at the GIT History, I see evidence that I tested the Gerrit push for me. There is an ugly merge around a concurrent commit by you. Ugly. Exactly why I try hard to avoid Gerrit. One should have rebased. Are you sure you logged in to Gerrit? Are you sure you +2'ed. https://projects.eclipse.org/projects/modeling.modisco/who shows you as a committer so you should have the same rights as me, but it is not unknown for the EF to mess up, perhaps demoting you from co-project lead had an unwanted side effect. I think that changing a commit requires extra Gerrit skills. Try committing a really boring single commit fix and see if that works. If so, abandon your current effort and reGerrit as a single change. Otherwise the old-fashioned way should work. Invite another committer to review a development branch and push directly after a +1 or reasonable delay (perhaps two pings at weekly intervals). If you have time to stay with the project, I'll try to keep you in my bug fixing loop.
New Gerrit change created: https://git.eclipse.org/r/156536
(In reply to Ed Willink from comment #18) > > Are you sure you logged in to Gerrit? Are you sure you +2'ed. Hi Ed, i do not have acces to the +2 radio button, only the +1. > > https://projects.eclipse.org/projects/modeling.modisco/who shows you as a > committer so you should have the same rights as me, but it is not unknown > for the EF to mess up, perhaps demoting you from co-project lead had an > unwanted side effect. > > I think that changing a commit requires extra Gerrit skills. Try committing > a really boring single commit fix and see if that works. If so, abandon your > current effort and reGerrit as a single change. I have tried with another single commit, and it is the same. Yes, possibly side-effect from co-lead retirement. May be you, you will have access to a +2 button (if i add you as reviewer) ? https://git.eclipse.org/r/#/c/156536/ > > Otherwise the old-fashioned way should work. Invite another committer to > review a development branch and push directly after a +1 or reasonable delay > (perhaps two pings at weekly intervals). If you have time to stay with the > project, I'll try to keep you in my bug fixing loop. ok otherwise i will try this way if possible.
(In reply to Fabien Giquel from comment #20) > i do not have acces to the +2 radio button, only the +1. I just pushed a Gerrit, without problem. The Push dialog echo is: Repository ssh://ewillink@git.eclipse.org:29418/modisco/org.eclipse.modisco Processing changes: new: 1, refs: 1 (\) Processing changes: new: 1, refs: 1 (\) Processing changes: new: 1, refs: 1 (\) Processing changes: new: 1, refs: 1, done (W) 48df27d: commit subject >50 characters; use shorter first paragraph (W) 48df27d: too many commit message lines longer than 72 characters; manually wrap lines ---------- Reviewing commit: 48df27d5 Authored by: Ed Willink <ed@willink.me.uk> The author is a committer on the project. This commit passes Eclipse validation. New Changes: https://git.eclipse.org/r/156772 [559205] Correct http://www.eclipse.org/modisco/utils/chart/0.11.incubation/i... (I don't bother with signed off by unless I have to.) The Gerrit ran, and after waiting 5 minutes for the slow archiving bug, the Gerrit showed a successful build. I could Reply... and get +/-2 for review, +/-1 for verified. +2 and I can Submit. Browsing my Gerrit settings to see why I might be a 'better' user than you, I see that my groups include "modeling.modisco". The project name evolved from mdt-modisco to just modisco with at least four setting corruptions. Maybe you still have "modeling.mdt.modisco".
(In reply to Ed Willink from comment #21) > The project name evolved > from mdt-modisco to just modisco with at least four setting corruptions. See e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=553423#c14 https://bugs.eclipse.org/bugs/show_bug.cgi?id=553082#c4 I have no write access to the project Gerrit settings.
(In reply to Ed Willink from comment #22) > I have no write access to the project Gerrit settings. I have forwarded the problem to infra, waiting for help : https://bugs.eclipse.org/bugs/show_bug.cgi?id=559661 (I cannot either make direct push to master, access denied)
New Gerrit change created: https://git.eclipse.org/r/156826
Gerrit change https://git.eclipse.org/r/156826 was merged to [master]. Commit: http://git.eclipse.org/c/modisco/org.eclipse.modisco.git/commit/?id=06e0d7d9b0a5970aa55b6026939ff97a0e8a05ef
(In reply to Ed Willink from comment #12) > Please push the fix. I am increasingly reluctant to go with amputation since > I lack the understanding of the code to accurately identify exactly where to > amputate. I have pushed fix specific to component org.eclipse.modisco.usecase.simpletransformationschain : get rid of "UML2Copy.atl/BidirectionalAssociation.atl" files, replaced by a simple uml refinement written in Java. It allows - make work again the both discoverers "Discover UML model with bidirectional associations from Java project", and "Create UML model with real types information on associations", at least for simple interactive cases in my workpsace, and so "SimpleBlackBoxDiscovery" junit test are reactivated in pom.xml. There is still the another "UML2Copy.atl" file in component "org.eclipse.modisco.usecase.perfannotatedumlstatechart", which is not exposed from any feature (api or ui action), but proposed through manual import and ant launch.
(In reply to Fabien Giquel from comment #26) > I have pushed fix specific to component > org.eclipse.modisco.usecase.simpletransformationschain I've not reviewed, but more tests passing is encouraging. Have you checked whether the Bug 559016 repro is fixed? > There is still the another "UML2Copy.atl" file in component > "org.eclipse.modisco.usecase.perfannotatedumlstatechart", which is not > exposed from any feature (api or ui action), but proposed through manual > import and ant launch. Can you identify a JUnit test that comes close to exercising this? Can you suggest user actions that could exercise it? If it is totally inaccessible, we could amputate, but much more easily just deprecate and atrophy.
(In reply to Ed Willink from comment #27) > Have you checked whether the Bug 559016 repro is fixed? the bug 559016 is not fixed, i obtain the same error with its .xmi file "Cannot set feature uml!Model.packagedElement to value org.eclipse.uml2.uml.internal.impl.PropertyImpl". The fact is that Sagar uses the simple "kdm->uml" transformation, not the advanced "kdm->uml with bidirectional types, or real types" that used the UML2Copy.atl. > Can you identify a JUnit test that comes close to exercising this? Can you > suggest user actions that could exercise it? If it is totally inaccessible, > we could amputate, but much more easily just deprecate and atrophy. No junit, no user actions from installed update site : i understand now that this particular project is not in the update site (not a plugin). The base README.TXT proposes to use it through a manual git checkout in workspace. We may remove it from git, OR indicate it as obsolete and unmaintained in README.TXT.
(In reply to Fabien Giquel from comment #28) > We may remove it from git ... Yes, org.eclipse.modisco.usecase.perfannotatedumlstatechart is dead. Bug 559718 raised to move it to archive.
(In reply to Fabien Giquel from comment #28) > (In reply to Ed Willink from comment #27) > > > Have you checked whether the Bug 559016 repro is fixed? > > the bug 559016 is not fixed, i obtain the same error with its .xmi file > "Cannot set feature uml!Model.packagedElement to value > org.eclipse.uml2.uml.internal.impl.PropertyImpl". The fact is that Sagar > uses the simple "kdm->uml" transformation, not the advanced "kdm->uml with > bidirectional types, or real types" that used the UML2Copy.atl. I reproduce by putting the briskheat-bhx-service_kdm.xmi file in a Java project in a nested Eclipse and then invoking Discovery->Discovers->Discover UML from KDM Model... which seems like the obvious thing to do. My initial diagnosis was to disclaim all packagedElement assignment under UML2 5.0.0, but actually it' s only some that are bad. There is a genuine need to upgrade the transformation(s) to at least avoid the illegal assignments.
(In reply to Ed Willink from comment #30) > Discovery->Discovers->Discover UML from KDM Model... Sorting out KDMtoUML / suppressing this menu entry is Bug 559506.
