Hi
You're missing the point. QVTo is doing precisely what it is told to
do. Process unordered elements.
You can abandon QVTo and use something that preserves accidental
order.
You can modify QVTo transformations to keep recreating ordering.
Best choice: You can modify/use modified source metamodels that
specify the ordered as you actually require.
Next best choice: you modify your final stage (Xtend/Java) to create
a repeatable ordering.
(I find the enhanced Xtend facilities confusing and inconsistent and
the tooling depressingly inferior to Java, so I only use Xtend when
I need template literals for model-to-text.)
Regards
Ed Willink
On 13/04/2015 21:09, Christian W. Damus
wrote:
Thanks, Ed.
The XMI IDs are not a difficult problem; I have that in
hand (though I’ll take a look at your references). The
greater concern for me is the stable code ordering problem.
The approach in the current tests generation prototype is a
pipeline of transformations like so:
GMFGen model describing the diagram
-> UML model describing the digram
-> UTP model describing the tests
-> Java code implementing the tests
The first transformation is a QVTo mapping from GMFGen to a
UML model comprising InstanceSpecifications. These are
instances of UML class model of the GMFGen metamodel.
Already, the contents of this UML model are randomly ordered
because of the way the QVTo is formulated.
The second transformation is a QVTo mapping from these UML
instance specifications to a model of test context classes and
test case operations, an instance of the UML Test Profile.
Again everything is randomly ordered, in part because the
QVTo deliberately creates (or converts) all collections as
Sets. But even when that is fixed, all of the collection
properties in the model are implemented as sets by QVTo
anyways, which needs an ugly and pervasive Java hack to get
around.
The end result is that the last transformation, Xtend
codegen templates, generates randomly ordered Java code in a
different ordering every time.
Employing orderedBy(name) all over the QVTo scripts won’t
help because the core problem is still that UML properties are
implemented by QVTo as sets (well, most of them are). So
collections will end up randomly ordered, anyways.
So, I guess what I need is either a way to tell QVTo not to
implement the UML metamodel’s uniqueness/orderedness
constraints in its collections and just use the ELists as they
are *or* use something else than QVTo. Or I have missed
something else?
Xtend does offer supra-Java facilities that are
particularly useful for model-to-model transformations, such
as create operations and dispatch operations which together
make a pretty slick mapping capability. Java 8 is catching up
with other Xtend language features, but Papyrus isn’t at Java
8 yet, either.
Thanks,
Christian
On Mon, Apr 13, 2015 at 3:48 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
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
_______________________________________________
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
|