Eclipse Community Forums: Epsilon » confusing IToolNativeTypeDelegate policy

Home » Modeling » Epsilon » confusing IToolNativeTypeDelegate policy

confusing IToolNativeTypeDelegate policy [message #631051]

Tue, 05 October 2010 20:07

Eclipse User

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.

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

Wed, 06 October 2010 03:28

Eclipse User

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.
>
>
>
>
>

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

Thu, 14 October 2010 12:37

Eclipse User

I would suggest mentioning this somewhere in the documentation.

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

Thu, 14 October 2010 16:03

Eclipse User

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.
>

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

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:59:25 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter