eclipse-modisco-bot
commented
3 days ago Jan 13, 2020 10:09
New Gerrit change created: https://git.eclipse.org/r/155758
Open eclipse-modisco-bot opened 3 days ago
eclipse-modisco-bot
commented
3 days ago Jan 13, 2020 10:09
New Gerrit change created: https://git.eclipse.org/r/155758
eclipse-modisco-bot
commented
3 days ago Jan 13, 2020 10:28
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
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 13, 2020 10:35
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.
eclipse-modisco-bot
commented
3 days ago By Hugo Bruneliere on Jan 14, 2020 08:19
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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 15, 2020 04:55
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:
(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.
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 15, 2020 05:38
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 17, 2020 04:06
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 22, 2020 04:41
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 23, 2020 14:21
(In reply to Hugo Bruneliere from comment #4)
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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 23, 2020 15:18
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)
THis is a 2017 red herring.
The true Ecore2ATLCopier.atl is from 2010, Google-able at:
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.
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 24, 2020 04:14
(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 :
Ed tell me if you are ok, OR if you think to go on UML features amputation.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 24, 2020 04:32
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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 24, 2020 04:52
(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/Ecore2Copierwhich looks much more promising. In particular the UMLCopier launch uses UML2 5.0.0.
AND
it excludes derived, transient, not changeable features.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 24, 2020 06:14
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 24, 2020 07:01
(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.
eclipse-modisco-bot
commented
3 days ago Jan 24, 2020 08:26
New Gerrit change created: https://git.eclipse.org/r/156518
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 24, 2020 10:27
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 24, 2020 11:21
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.
eclipse-modisco-bot
commented
3 days ago Jan 24, 2020 12:44
New Gerrit change created: https://git.eclipse.org/r/156536
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 27, 2020 04:15
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 28, 2020 16:24
(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".
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 28, 2020 16:38
(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.
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 29, 2020 09:03
(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)
eclipse-modisco-bot
commented
3 days ago Jan 29, 2020 12:00
New Gerrit change created: https://git.eclipse.org/r/156826
eclipse-modisco-bot
commented
3 days ago Jan 29, 2020 12:28
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
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 29, 2020 12:56
(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
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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 30, 2020 04:11
(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.
eclipse-modisco-bot
commented
3 days ago By Fabien Giquel on Jan 30, 2020 08:18
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 30, 2020 11:21
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 30, 2020 11:37
(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.
eclipse-modisco-bot
commented
3 days ago By Ed Willink on Jan 30, 2020 12:19
(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.
| --- | --- | | Bugzilla Link | 559115 | | Status | NEW | | Importance | P3 major | | Reported | Jan 13, 2020 10:03 EDT | | Modified | Jan 30, 2020 12:19 EDT | | See also | Gerrit change https://git.eclipse.org/r/155758, Git commit da3874be, 552989, 559016, 423935, 557989, 559506, Gerrit change https://git.eclipse.org/r/156518, Gerrit change https://git.eclipse.org/r/156536, Gerrit change https://git.eclipse.org/r/156826, Git commit 06e0d7d9, 559718 | | Reporter | Ed Willink |
Description
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?