Eclipse Community Forums: TMF (Xtext) » [mwe2] Resolving platform:/plugin

Home » Modeling » TMF (Xtext) » [mwe2] Resolving platform:/plugin

[mwe2] Resolving platform:/plugin [message #714686]

Thu, 11 August 2011 04:59

Eclipse User

Hi

I need to resolve

platform:/plugin/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel

within my workflow.

When using CVS, I made do with a URI mapping to a relative path that
required org.eclipse.xtext.common.types to be imported as a project into
the workspace.

Since moving to GIT the relative path collapses; unless I put
org.eclipse.xtext.common.types into my GIT.

---------------

The following appears to solve the problem by allowing access to the
true plugin:

Launch with an additional parameter: --param eclipse_home=${eclipse_home}

In the workflow:

var eclipse_home

Workflow {
bean = ResourceSetImpl : resourceSet {}
bean = StandaloneSetup { resourceSet = resourceSet
platformUri = ".."
platformUri = "${eclipse_home}"
registerGeneratedEPackage =
"org.eclipse.xtext.common.types.TypesPackage"
uriMap = Mapping {
from = "platform:/plugin/org.eclipse.xtext.common.types/"
to = "platform:/resource/org.eclipse.xtext.common.types/"
}
}

-------------

Is there a better way?

Since eclipse_home is rather useful, shouldn't the MWE launcher provide
it automatically?

Perhaps StandaloneSetup should have an "eclipseHome" Property to
configure EcorePlugin's plugin map correctly.

The MWE2 documentation seems to overlook this useful parameter passing
ability.

Is it a bug that platformUri can be set twice?

Regards

Ed Willink

Re: [mwe2] Resolving platform:/plugin [message #714849 is a reply to message #714686]

Thu, 11 August 2011 11:27

Eclipse User

Hi Ed,

please try to set StandaloneSetup#scanClassPath to true.
That should take care of most of the other configuration that you did.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

On 11.08.11 10:59, Ed Willink wrote:
> Hi
>
> I need to resolve
>
> platform:/plugin/org.eclipse.xtext.common.types/model/JavaVMTypes.genmodel
>
> within my workflow.
>
> When using CVS, I made do with a URI mapping to a relative path that
> required org.eclipse.xtext.common.types to be imported as a project into
> the workspace.
>
> Since moving to GIT the relative path collapses; unless I put
> org.eclipse.xtext.common.types into my GIT.
>
> ---------------
>
> The following appears to solve the problem by allowing access to the
> true plugin:
>
> Launch with an additional parameter: --param eclipse_home=${eclipse_home}
>
> In the workflow:
>
> var eclipse_home
>
> Workflow {
> bean = ResourceSetImpl : resourceSet {}
> bean = StandaloneSetup { resourceSet = resourceSet
> platformUri = ".."
> platformUri = "${eclipse_home}"
> registerGeneratedEPackage = "org.eclipse.xtext.common.types.TypesPackage"
> uriMap = Mapping {
> from = "platform:/plugin/org.eclipse.xtext.common.types/"
> to = "platform:/resource/org.eclipse.xtext.common.types/"
> }
> }
>
> -------------
>
> Is there a better way?
>
> Since eclipse_home is rather useful, shouldn't the MWE launcher provide
> it automatically?
>
> Perhaps StandaloneSetup should have an "eclipseHome" Property to
> configure EcorePlugin's plugin map correctly.
>
> The MWE2 documentation seems to overlook this useful parameter passing
> ability.
>
> Is it a bug that platformUri can be set twice?
>
> Regards
>
> Ed Willink

Re: [mwe2] Resolving platform:/plugin [message #714941 is a reply to message #714849]

Thu, 11 August 2011 15:57

Eclipse User

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Sebastian 
 
Thanks. Yes, scanClassPath solves the need to mess around with an
eclipse_home, but it is still necessary to have 
 
        uriMap = Mapping {
 
            from = "platform:/plugin/org.eclipse.xtext.common.types/"
 
            to = "platform:/resource/org.eclipse.xtext.common.types/"
 
         }
 
 
which seems a little redundant if scanClasspath has found all the
plugin resources. 
 
    Regards 
 
        Ed Willink 
 
On 11/08/2011 16:27, Sebastian Zarnekow wrote:
<blockquote cite="mid:j20roc$f9u$2@news.eclipse.org" type="cite">Hi
Ed,
 
 
please try to set StandaloneSetup#scanClassPath to true.
 
That should take care of most of the other configuration that you
did.
 
 
Regards,
 
Sebastian
 
</blockquote>
 
</body>
</html>

Re: [mwe2] Resolving platform:/plugin [message #714942 is a reply to message #714941]

Thu, 11 August 2011 16:21

Eclipse User

Hi Ed,

your are right.
Could you please file a ticket and describe your usecase, especially why
you had to use platform:/plugin instead of platform:/resource uris.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

On 11.08.11 21:57, Ed Willink wrote:
> Hi Sebastian
>
> Thanks. Yes, scanClassPath solves the need to mess around with an
> eclipse_home, but it is still necessary to have
>
> uriMap = Mapping {
> from = "platform:/plugin/org.eclipse.xtext.common.types/"
> to = "platform:/resource/org.eclipse.xtext.common.types/"
> }
>
> which seems a little redundant if scanClasspath has found all the plugin
> resources.
>
> Regards
>
> Ed Willink
>
> On 11/08/2011 16:27, Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> please try to set StandaloneSetup#scanClassPath to true.
>> That should take care of most of the other configuration that you did.
>>
>> Regards,
>> Sebastian
>

Re: [mwe2] Resolving platform:/plugin [message #715014 is a reply to message #714942]

Fri, 12 August 2011 01:15

Eclipse User

https://bugs.eclipse.org/bugs/show_bug.cgi?id=354575

On 11/08/2011 21:21, Sebastian Zarnekow wrote:
> Hi Ed,
>
> your are right.
> Could you please file a ticket and describe your usecase, especially
> why you had to use platform:/plugin instead of platform:/resource uris.
>
> Regards,
> Sebastian

Previous Topic:	Template proposals despite "Too many constants"
Next Topic:	Ctrl+hover does not show hyperlink

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 16 11:54:44 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter