Move to Maven/Tycho for projects and build infrastructure #858
Comments
|
@szarnekow I might need your help here for this failing test @Test
public void testBug346035_01() throws Exception {
// @formatter:off
String grammarAsString =
"grammar test with org.eclipse.xtext.common.Terminals\n" +
"import 'platform:/resource/org.eclipse.xtext.xbase/model/Xbase.ecore' as xbase\n" +
"generate myDsl 'uri'\n" + "Model: elements+=Element*;\n" +
"Element returns xbase::XExpression : {Element} 'Hello';\n" +
"terminal ID : '^'?('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;\n";
// @formatter:on
getResourceFromString(grammarAsString);
}If I understand correctly, this verifies that you can import an Ecore from the classpath (as a resource). This is test is located in This test fails (it cannot locate To make it pass ALSO from Eclipse, I created a source folder in the Is this solution OK for you? I'm wondering if this test works when run from Eclipse with the current buildship infrastructure. @cdietrich I don't have the workspace with the master branch with buildship, would you please mind trying running that? I mean as a JUnit test (i.e., NOT with gradle). Thanks! |
|
no the test is also red in buildship based eclipse |
|
@cdietrich thank you for the feedback! Then I was right. However, my current solution does not make me feel comfortable: Having Xbase.ecore twice might undermine Plugin tests and the running workbench (started from our development environment). I'd go with a slightly different solution: put in Of course, let's wait also for @szarnekow feedback; in the meantime, I'll apply the approach I've just mentioned and in case I'll undo it. |
|
i wonder if you added xbase to the required bundles. shouldnt it then be resolvable? have no idea how tests do uri mapping |
|
If I add xbase as a required bundle (as I did at the beginning and as it is now in the buildship configuration), the test will find |
|
thus is wonder if the test misses some mapping or so. does the second Xtext2EcoreTransformer test work? |
|
all the other tests work. Which one are you referring to? |
|
org.eclipse.xtext.xtext.ecoreInference.Xtext2EcoreTransformerTest |
|
Not in this repository, right? |
|
no in core |
|
OK, in that homonymous class we never use |
|
lets see what sebastian says |
|
Yes, let's wait for @szarnekow . In the meantime, I implemented an alternative solution (replacing the working one that I first described in my first comment): LorenzoBettini@7602ba7 If I understand correctly how that testcase and that specific test works, this should be equivalent. |
|
I’ll only have the mid next week to look into this in detail. EMF has a lot of code to interpret build.properties before packaging. The test should just work both in mvn and from Eclipse as plug-in test. I’ll follow up as soon as I understand the problems you’re seeing |
|
@szarnekow I forgot to mention that I had also tried to run that as a Plug-in test and it fails as well; Even worse, when run as plug-in tests I get also other failures in other tests. This one that cannot resolve
And this one
with this strange error about |
|
@szarnekow some additional findings: by creating the development environment with the new temporary Oomph instructions found here: eclipse/xtext-core#2054 (comment) there's a new failure from Eclipse Since in this setup |
|
Concerning this last problem (when xtext-core and xtext-extras are in the same workbench), I found this possible solution, which can be reverted if it doesn't sound OK: eclipse/xtext-core@959bc13 The idea is to have a source folder I had also try to simply put Xtext.ecore and genmodel into the main source folder respecting The above solution does not seem to break anything: it's just a trick to force the Eclipse builder to copy the ecore file in the output folder. |
|
Might be a bug in the classpath URI handler. As discussed in another thread: We need to figure the root cause for this and fix that one instead of patching around the layout of the jars. |
In Eclipse, so that tests in org.eclipse.xtext.extras can resolve URI "classpath:/org/eclipse/xtext/Xtext.ecore"
So should I revert that commit for the moment? Note that the above solution is NOT patching the layout of the JAR, which stays the same. In any case, if I understand correctly, if the current classpath consists of target platform dependencies and open projects' output folders, when org.eclipse.xtext is an open project in the workspace, the Xtext.ecore file cannot be found in any output folder (that's why I tried the above solution). |
|
@szarnekow actually the layout of the JAR had changed (my bad!); it should be back to the original layout with eclipse/xtext-core@585b891 However, we can always revert the change I described in my previous comments if you think it's a hack. |
This is a plugin test and therefore the classpath URI mappings in Please note that extras.tests needs a dependency to xbase. |
Yes, that looks like a hack and should not be necessary. Please note that |
|
@szarnekow sorry but I'd need you to be more specific ;) could you please paste the version you patched of that test? I removed all the URI mappings where you said in that test, but it fails because missing org.eclipse.xtext.tests: Assert.assertFalse(resourceSet.getResource(URI.createURI(
"platform:/plugin/org.eclipse.xtext.tests/src/org/eclipse/xtext/metamodelreferencing/tests/EcorePerNsURI.ecore"),
true).getContents().isEmpty()); |
|
@szarnekow I think I got it! I added xbase as a dependency of xtext.extras and then I made this change: 8c96d42 So I couldn't remove all mappings. Is that what you meant? This way, by running extras.tests as plug-in tests (headless mode, no need of UI), they all pass. I then modify the POM so that we run its tests with tycho-surefire instead of maven-surefire. Actually, there was another small adjustment to make: this test @Test public void testPerformance() throws Exception {
GenericResourceDescriptionManager manager = getEmfResourceDescriptionsManager();
Collection<String> uris = ImmutableList.copyOf(EPackage.Registry.INSTANCE.keySet());
for(String uri: uris) {
EPackage pack = EPackage.Registry.INSTANCE.getEPackage(uri);
IResourceDescription description = manager.getResourceDescription(pack.eResource());
assertNotNull(description);
for(int i = 0; i < 10; i++) {
Iterator<EObject> iter = EcoreUtil.getAllProperContents(pack, true);
while(iter.hasNext()) {
EObject next = iter.next();
if (next instanceof ENamedElement) {
String name = ((ENamedElement) next).getName();
// Iterable<IEObjectDescription> objects =
description.getExportedObjects(EcorePackage.Literals.EOBJECT, QualifiedName.create(name), false);
// assertFalse(name + " - " + uri + " - " + next, Iterables.isEmpty(objects));
}
}
}
}
}Because of this exception: I seem to understand that this test tries to load all EPackage contents in the running instance. It finds To solve that, I turned all the source folders of Another possible solution is to filter the contents of I'll check what happens in a workspace where other projects are imported (e.g., also those of |
|
If it makes tycho happy, I'm ok with marking the source folders of test projects as regular source folders. |
|
with repo merge this is done |
See also eclipse/xtext-lib#499 and eclipse/xtext-core#2052
Development has started in my fork's branch: https://github.com/LorenzoBettini/xtext-extras/tree/lb_2052_maven_tycho
The text was updated successfully, but these errors were encountered: