Set Xtend compiler to not clean the generated files during clean build.
So the public API types do not get lost when API builder is running and
Xtend comiler is not done.
Change-Id: I327f8e4859d0e18792d29aadb7bee5597aba204b
Signed-off-by: Dennis Huebner <dennis.huebner@itemis.de>
Also added some eclipse runtime constraints
Change-Id: Ic42f9dfda922626dcfd3cecf57f4a40971701f6e
Signed-off-by: Dennis Huebner <dennis.huebner@itemis.de>
Some of our tests seem to depend on index data to
be present or some other unpredictable things. The
JUnit TestRule Flaky.Rule tries to deal with those
symptomatically. By annotating a test method as
@Flaky, one can indicate that the test should be
executed again if it failed. The number of trials
can be configured and defaults to 3.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=442349
Change-Id: Ic405b64b3c5c46350fd8a954d6791bf65978a732
JvmInnerTypeReferences are used to represent types
of the form Outer<T>.Inner which is necessary to keep
track of parameterized inner classes.
This change had some impact on the overall constraints
and invariants for LightweightTypeReferences.
Therefore the ITypeReferenceOwner is now responsible to create
instances of LightweightTypeReference from JvmTypeReferences,
JvmTypes or Classes. Various factory methods have
been added. Those will maintain the invariants, e.g.
InnerTypeReferences are produced where appropriate.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=417675
Change-Id: I6fdaa49851dc70edebb889ef9482412232fca8a0
TypeReference#is was removed as we decided to support properly implemented equals and hashcode. Inferred type references won't lazily resolve (i.e. mutate). During the first two phases those type references are always inferred. During validation and generation we create proper TypeReference instances again.
Change-Id: I3eaf01a8702a09b77aed88b899d67f0650600ed4
For assigned actions that live in a multi-cardinality group we need to also add the Actions type as the feature.
Change-Id: I7b7d756bd6db15b0af1ca137c3135ce2aad1193b
Do not unload generated packages since they cannot
be referenced in the same resource set anyway and it
caused trouble: An edit to a GrammarResource triggered
proxification of the generated package and when the
serializer tried to persist the grammar resource, the
proxies would have been resolved again but there is no
physical resource for the generated resource URI
which will put a dummy XMIResource into the resource
set. Afterwards, that would be broken.
Change-Id: Ida5a7b8edbaf3a1d5914a795c0afa90ff5a89fcc
By running a test suite with the XtextSmokeTestRunner,
all test cases in that suite will be used to extract
smoke test scenarios generically. Clients choose how
to process the input by means of the ProcessedBy annotation
on the test suite.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=441458
Change-Id: I1be69cf2361590a76a4fe9d0152933a2aabc83fc
Instead of lazy initialization in the getters, the
accessor fields are assigned in the constructor of the
grammar access.
Also the grammar EObjects are fully resolved before
they are obtained from the grammar provider.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=358352
Change-Id: I7398e6d61b99b035a364ae95d7b149bb4e0e30cb
Also tweaked subtype proposals in common.types.
As soon as we switched to Helios, the reflective
code can be removed.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=440951
Change-Id: Ia25580d5956e84245abbf2b9b7b5a478d3bcaaa7
