Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » confusing IToolNativeTypeDelegate policy
confusing IToolNativeTypeDelegate policy [message #631051] Wed, 06 October 2010 00:07 Go to next message
alexili is currently offline 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.




Re: confusing IToolNativeTypeDelegate policy [message #631099 is a reply to message #631051] Wed, 06 October 2010 07:28 Go to previous messageGo to next message
Dimitrios Kolovos is currently offline 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.
>
>
>
>
>
Re: confusing IToolNativeTypeDelegate policy [message #632924 is a reply to message #631099] Thu, 14 October 2010 16:37 Go to previous messageGo to next message
alexili is currently offline alexili
Messages: 3
Registered: October 2010
Junior Member
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 20:03 Go to previous message
Dimitrios Kolovos is currently offline 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.
>
Previous Topic:Running ETL examples
Next Topic:accessing eContainer and other e* properties
Goto Forum:
  


Current Time: Fri Oct 31 04:57:26 GMT 2014

Powered by FUDForum. Page generated in 0.05425 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software