| .ecore models in linked folders not indexed [message #854255] |
Mon, 23 April 2012 20:33  |
|
In project Spray we faced the problem that .ecore models from the development workspace were not indexed. We are referring to EClasses in our DSL. It works from plugin Jars, and when importing the metamodel project (with Xtext nature enabled) into the runtime workspace.
After some debugging I have came to JdtToBeBuiltComputer#wasFragmentRootAlreadyProcessed(). In the case of the .ecore file being in a development workspace project, the project's name of variable otherProject has value '.org.eclipse.jdt.core.external.folders'. The condition
previouslyBuilt.contains(otherProject.getName())
returns true and subsequently ignores this "project". Further this "project" has no Xtext nature, although the original project has the nature.
The URI has e.g. this value:
platform:/resource/.org.eclipse.jdt.core.external.folders/.link14/org/eclipselabs/spray/styles/Style.ecore
As a first test I have overwritten JdtToBeBuiltComputer with a overridingGuiceModule, and just returning 'false' when 'otherProject' is pointing the the external linked folder:
IProject otherProject = pair.getSecond();
if (".org.eclipse.jdt.core.external.folders".equals(otherProject.getName()))
return false;
I consider this as an ugly workaround, but what would be the appropriate solution? Is this intended behavior or a bug?
Best wishes,
~Karsten
Need professional support for Xtext, EMF, Eclipse IDE?
Go to: http://devhub.karakun.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
|
|
|
| Re: .ecore models in linked folders not indexed [message #854273 is a reply to message #854255] |
Mon, 23 April 2012 20:53  |
 Sebastian Zarnekow
Messages: 3108
Registered: July 2009 |
Senior Member |
|
|
Hi Karsten,
that's actually a p2 bug. Folders that are not on the classpath are not
visible from the development workspace in the runtime workspace.
Please note the following case in the JdtToBeBuildComputer
boolean process = XtextProjectHelper.hasNature(otherProject);
String otherName = otherProject.getName();
if (!process) {
process = otherProject.isAccessible() && otherProject.isHidden();
If the project does not have the Xtext nature but is both hidden and
accessible, it is scheduled for indexing thus its contents is processed
by the builder.
You may want to dig into
PackageFragmentRootWalker.traverse(IPackageFragmentRoot, boolean) to
verify this (since the projects contents is cached, a clean build may be
necessary to trigger the indexing of the hidden project).
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 23.04.12 22:33, schrieb Karsten Thoms:
> In project Spray we faced the problem that .ecore models from the
> development workspace were not indexed. We are referring to EClasses in
> our DSL. It works from plugin Jars, and when importing the metamodel
> project (with Xtext nature enabled) into the runtime workspace.
> After some debugging I have came to
> JdtToBeBuiltComputer#wasFragmentRootAlreadyProcessed(). In the case of
> the .ecore file being in a development workspace project, the project's
> name of variable otherProject has value
> '.org.eclipse.jdt.core.external.folders'. The condition
> previouslyBuilt.contains(otherProject.getName())
> returns true and subsequently ignores this "project". Further this
> "project" has no Xtext nature, although the original project has the
> nature.
> The URI has e.g. this value:
> platform:/resource/.org.eclipse.jdt.core.external.folders/.link14/org/eclipselabs/spray/styles/Style.ecore
>
>
> As a first test I have overwritten JdtToBeBuiltComputer with a
> overridingGuiceModule, and just returning 'false' when 'otherProject' is
> pointing the the external linked folder:
>
> IProject otherProject = pair.getSecond();
> if
> (".org.eclipse.jdt.core.external.folders".equals(otherProject.getName()))
> return false;
>
> I consider this as an ugly workaround, but what would be the appropriate
> solution? Is this intended behavior or a bug?
>
> Best wishes,
> ~Karsten
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02355 seconds
Search
Help
Register
Login
Home
