Hi Christian
In principle you are asking for the output model to exhibit a
characteristic that is an accidental rather than specified
characteristic of the input model, and so it is only exhibited by a
helpful EList implementation.
There is certainly a lot to be said for Xtend for model-to-text, but
in this case I see little that Xtend offers compared to Java; indeed
it seems an example where Xtend is IMHO worse than Java.
If you want to stay within OMG tooling, you can modify your QVTo to
have ->sortedBy(...) at all relevant points.
Perhaps your problem is really in UML2 whose inability to stabilize
xmi:ids is very unhelpful for e.g. Ecore2UML.
For the UML-derived OCL pivot model I ensure that all xmi:ids are
derived algorithmically ensuring that they are stable, reproducible
and even predictable for references to future models. This uses Java
Switch-based code.
See org.eclipse.ocl.pivot.uml.internal.utilities.UMLXMIID which
suits my purposes. It is not necessarily suitable for arbitrary
usage.
Regards
Ed Willink
On 13/04/2015 20:19, Christian W. Damus
wrote:
Hi,
In my attempts to modify the QVTo transformations in the
test generation framework to output model elements in a
consistent order in each execution (to fix the problem of UTP
models being randomly ordered and, hence, the generated code),
I have so far concluded that QVTo is the wrong transformation
language. I think it would be necessary to override every
access and modification of list-valued properties of UML model
elements with Java black-box operations, which rather defeats
the purpose of a high-level language like QVTo.
The problem is that QVTo dogmatically applies the
uniqueness and ordering attributes of properties in the UML
metamodel. Consequently, most collections end up being
implemented by QVTo as randomly-ordered Sets. The only way to
work around that is to access these collections via Java
black-box operations that just operate directly on the
collections as Lists (QVTo Sequences).
Doing this consistently would pretty much rewrite all of
our QVTo transformations, which then begs the question Why
wouldn’t I just rewrite them all in Xtend, which in addition
to treating collection properties natively as the Lists that
they are, provides more seamless integration with Java
(including debugging and searching)?
Thoughts? Would any of the QVTo experts on the Papyrus
team know what I’m missing (if, indeed, I’m missing anything)?
Thanks,
Christian
On Mon, Apr 13, 2015 at 8:42 AM, Christian W. Damus <give.a.damus@xxxxxxxxx>
wrote:
Hi, Benoit,
I see now. I agree that some kind of “generated with
version x.y.z of the framework” notation somewhere in
the output would be valuable. With EMF it’s perhaps
implicit in the settings of the GenModel (which target
EMF version does it specify) and the git commit
timestamp. But something more explicit would not be
difficult.
My latest revision of the Gerrit change adds the
first (most simple) tests for canonical synchronization,
as demonstrated here.
Up next I plan to tackle the problem of regeneration
utterly changing very file, which is terrible for diffs
and SCM. As I see it there are two basic issues:
- UML models are generated with new
random UUIDs each time. These need to be replaced
by stable, predictable unique IDs, much as UML2 does
in the “Convert to Metamodel” action
- the UTP test model is generated in a
random order because the QVTo transformations use
sets for every collection. Consequently, the order
in which every particle of code is generated changes
each time
I’ll see how far I get with this
today.
Thanks,
Christian
On Wed, Apr 8, 2015 at 10:46 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx>
wrote:
Hi
Christian,
As you already know
J
I’m strongly advocating the fact to
remove all generated code from the repository
The generated code should always be
up to date with the model and not mixed with
some handcoded code.
BUT the generated test is here to
check any regression
Obviously if your generated tests
are up to date with your model your tests should
always pass
ð
That’s why the generation of the
tests should be done
manually (still bind to the build tool J )
For example :
- I made a very simple generator to
generate a junit test class for element type (I
hope to share it when the work is done)
(My main concern is to avoid any id
regression since ids can be specialized (so are
part of our api
J) )
- Let’s say that we get the last
official version for SysML 1.4, I will generate
the new elementtype file
- if the tests are generated at
runtime then they will use the new ids as input
and pass
- if the tests are manually
generated, they will failed on a regression (I
will have to
manually call the build tool for updating
them or patch my regression )
ð
That’s why generated test should
not be managed exactly like generated code (It
may have some exception)
About the “versionstamp”, it is
just a way to know the version of the tool that
generated the code
By experience there are some times
when you can’t regenerate the files
but much much worse you also don’t
know what version or even tool that was used.
ð
The best way would be to use a
file without semantic meaning (my recommendation
use package-info.java)
Regards,
Benoit
Thanks for the follow-up.
See some more responses to both of your
replies, in-line below.
On Wednesday, Apr 8, 2015 at
05:11, CADAVID Juan <juan.cadavid@xxxxxx>,
wrote:
Hi
Christian, Benoit,
Thanks
for updating the contribution. I’m having a
hard time finding time to work on the test
generator, but I see you were able to start
extending the transformations, and I will
follow up and your suggested changes.
I certainly don’t mind
continuing to work on this to get it up-to-date
with the current Mars codebase. I have
essentially planned this week to do that. It’s
a learning opportunity for me. :-)
Initially,
I wanted to submit two patches as Benoit
suggested, but I had some mutual
interdependencies which did not allow to
isolate one from the other (e.g. I put the
generation launcher in each diagramXX.tests
plugin, thus creating a depencency to
oep.test.framework). I’ll fix that as soon
as I can.
Again, I can see about the
feasibility of splitting this into separate
codegen/framework and generated-code patches
once I have the current patch working. I don’t
want to derail your schedule, and I’m already
into it.
Juan
Hi
Christian,
I’m not aware of all the
details, but yes it seems that this patch
is pushing new tests for most of the
diagrams.
It may be a good idea to
split the patch to separate :
-
the generator (+framework)
-
and the generated tests (for
each diagrams)
If we want to maintain this
generator, we should also add a “version
time stamped information”
in the one (many) of
generated files since the generated test
don’t follow the same lifecycle as
standard generated code.
Could you explain in more
detail what you mean by this? I’m not familiar
with a version timestamp pattern in code
generation, and I don’t know what lifecycle you
refer to.
Regards,
Benoit
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : mardi 7 avril 2015 16:50
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Where
is the code generator for diagram tests?
It appears that this
generates an entirely new suite of tests,
correct? I’ll take a look at extending
this framework to support my needs, which
are a bit peculiar because my test cases
are driven by edits in the semantic model,
not by edits in the diagram.
I expect I’ll be
returning to the mailing list for a good
deal of help in the next while … :-)
On Tue, Apr 7, 2015 at 2:17 AM, MAGGI
Benoit <Benoit.MAGGI@xxxxxx>
wrote:
Hi Christian,
I believe the
generator is Gerrit (here [1])
waiting for a review.
Regards,
Benoit Maggi
[1] :
https://git.eclipse.org/r/#/c/38587/
According
to the developer guide on the wiki
[1], there is a diagram tests
generation framework. It is also
referenced in the headers of some
source files as the “Papyrus Test
Framework”. Certainly, many of
the tests appear to be generated.
Where
is the code generator? I don’t
find the QVTo transformations
alluded to by the wiki
documentation. I don’t see the
UML Testing Profile in the
repository, nor any MWE workflows
or launch configurations that
would run test generation.
I
ask because I plan to add diagram
synchronization
(canonical-edit-policy) tests to
each diagram’s test bundle, and I
thought it would make sense to
investigate the possibility of
including some scaffolding at
least in the test generator.
Perhaps these tests were
generated once by something that
isn’t in the repository and have
ever since been maintained “by
hand”?
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4328/9529 - Release Date:
04/13/15
|
