Re: [m2t-dev] EMF 2.6 for Xpand 0.8.0?

[Achim Demelt <a.demelt@xxxxxxxxxxxxx>]

This new feature need not go into the core. There are absolutely no changes 
required in Xtend. It can be a separate plugin, which would have to be 
packaged into a separate feature for distribution/installation reasons.

What troubles me is that we have _one_ target platform for the whole project. 
So when one bundle requires EMF 2.6 to build, everything else will also be 
built against EMF 2.6. That's what I meant when I said that there might be a 
danger of using new API in places where we actually don't want to.

Does anyone know if the PDE API tools can check if your code uses EMF 2.6 API 
although the bundle dependency says it requires 2.5 or higher?

Achim

On Tuesday 29 December 2009 23:01:00 ekke wrote:
> a fragment would be a good idea, I think
> but perhaps not easy to distribute - extra download ? extra feature ?
> 
> support for EOperations would be great - just some days ago I run into
> missing this ;-)
> 
> ekke
> 
> Am 29.12.09 22:45, schrieb Karsten Thoms:
> > Would it be possible to implement that support in a fragment of
> > o.e.xtend ? Support for EOperations is requested with this feature
> > request:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=297515
> >
> > It is important that we do not require Eclipse 3.6 for core plugins
> > whenever possible.
> >
> > ~Karsten
> >
> > Am 29.12.2009 um 17:05 schrieb Achim Demelt:
> >> Hi guys,
> >>
> >> M2T Xpand is currently built against EMF 2.5. This is a good thing to
> >> guarantee stability and compatibility for our users. However there's
> >> a nice
> >> little feature that I would like to contribute to Xtend that requires
> >> EMF 2.6.
> >>
> >> EMF 2.6 can now delegate the invocation of EOperations and the
> >> getter/setter
> >> calls of EStructuralFeatures. It was pretty easy to come up with an
> >> implementation that allows you to specify the behavior of operations
> >> and the
> >> computation rules for derived properties (or even the behavior of
> >> non-trivial
> >> setters) with Xtend :-) All you need is some annotations in the
> >> *.ecore file.
> >> The behavior implementations themselves can either go inline into the
> >> ecore
> >> file as well, or be specified externally in *.ext files (in order to
> >> make use
> >> of content assist et al). I can check in a preview version if anyone is
> >> interested.
> >>
> >> Building everything against the EMF 2.6 SDK is probably not a good
> >> option,
> >> since this requires the Eclipse Platform 3.6. It's probably too
> >> dangerous,
> >> because we might accidentally introduce dependencies to EMF
> >> 2.6/Platform 3.6
> >> code and break our clients. What do you think? Is there a way to do this
> >> gracefully?
> >>
> >> Cheers,
> >> Achim
> >> _______________________________________________
> >> m2t-dev mailing list
> >> m2t-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/m2t-dev
> >
> > _______________________________________________
> > m2t-dev mailing list
> > m2t-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/m2t-dev
>