| .ecore models in linked folders not indexed [message #854255] |
Mon, 23 April 2012 16:33  |
Eclipse User |
|
|
|
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
|
|
|
| Re: .ecore models in linked folders not indexed [message #854273 is a reply to message #854255] |
Mon, 23 April 2012 16:53  |
| Eclipse User |
|
|
|
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
|
|
|
|
|
|
| Re: .ecore models in linked folders not indexed [message #897948 is a reply to message #897649] |
Wed, 25 July 2012 09:44 |
| Eclipse User |
|
|
|
At development time (when launching the runtime workspace) I haven't came up with way to avoid them since the linked folders/resources are created automatically by PDE. To make it work and test my DSLs I've to make several tweaks and launch the runtime workspace a couple of times so all the models (that are referred as linked resources) get indexed. Of course this doesn't happen on a production environment where all the plugins are released as jars.
It's a shame that PDE doesn't fix that, this impacts development time.
Regards,
Reynier
|
|
|
Powered by
FUDForum. Page generated in 0.05390 seconds
Home