Eclipse Community Forums: Epsilon » confusing IToolNativeTypeDelegate policy

Help

Home

Home » Modeling » Epsilon » confusing IToolNativeTypeDelegate policy

Show: Today's Messages :: Show Polls :: Message Navigator

confusing IToolNativeTypeDelegate policy [message #631051]

Wed, 06 October 2010 00:07

alexili

Messages: 3
Registered: October 2010

Junior Member

The default policy for a programmatically created module [

module = new EolModule();
try {
module.parse(eolSource);
} catch (URISyntaxException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}

module.getContext().getModelRepository().addModel(emf);

] is to resolve only class path native types. Thus, something like [ http://www.eclipse.org/gmt/epsilon/doc/articles/call-java-fr om-epsilon/] cannot be reproduced. I had to use the following workaround: [
List<IToolNativeTypeDelegate> delegates = module.getContext().getNativeTypeDelegates();
delegates.add(new ExtensionPointToolNativeTypeDelegate());
module.getContext().setNativeTypeDelegates(delegates);
]

It seems there is no reason at all to not include ExtensionPointToolNativeTypeDelegate() by default.

Report message to a moderator

Re: confusing IToolNativeTypeDelegate policy [message #631099 is a reply to message #631051]

Wed, 06 October 2010 07:28

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi,

The main reason why we're not including an
ExtensionPointToolNativeTypeDelegate in the default module configuration
is that it is Eclipse-specific. Our intention is to keep the core of
Epsilon free from any dependencies to Eclipse so that it can also be
used in plain Java applications.

Cheers,
Dimitris

On 06/10/2010 02:07, alexili wrote:
> The default policy for a programmatically created module [
>
> module = new EolModule();
> try {
> module.parse(eolSource);
> } catch (URISyntaxException e) {
> e.printStackTrace();
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> module.getContext().getModelRepository().addModel(emf);
>
> ] is to resolve only class path native types. Thus, something like
> [ http://www.eclipse.org/gmt/epsilon/doc/articles/call-java-fr om-epsilon/] cannot
> be reproduced. I had to use the following workaround: [
> List<IToolNativeTypeDelegate> delegates =
> module.getContext().getNativeTypeDelegates();
> delegates.add(new ExtensionPointToolNativeTypeDelegate());
> module.getContext().setNativeTypeDelegates(delegates);
> ]
>
> It seems there is no reason at all to not include
> ExtensionPointToolNativeTypeDelegate() by default.
>
>
>
>
>

Report message to a moderator

Re: confusing IToolNativeTypeDelegate policy [message #632924 is a reply to message #631099]

Thu, 14 October 2010 16:37

alexili

Messages: 3
Registered: October 2010

Junior Member

I would suggest mentioning this somewhere in the documentation.

Report message to a moderator

Re: confusing IToolNativeTypeDelegate policy [message #632966 is a reply to message #632924]

Thu, 14 October 2010 20:03

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

This makes sense. Could you please file an enhancement request for this
in the bugzilla?

Cheers,
Dimitris

alexili <alex@iliasov.org> wrote:
> I would suggest mentioning this somewhere in the documentation.
>

Report message to a moderator

Previous Topic:	Running ETL examples
Next Topic:	accessing eContainer and other e* properties

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 17:53:23 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter