Am 30.12.09 08:56, schrieb Achim Demelt:
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,
dont know if this helps:
MANIFEST.MF -> Dependency
set normal Bundle Dependency EMF 2.5 or higher using "Required
Plug-ins" or "Import Packages"
and under "Automated Management of Dependencies" add the EMF 2.6 Bundle
then: Dependency from Manifest is still 2.5, but PDE uses 2.6 for Build
dont know if it works in your environment and use-case - but perhaps
worth a try
ekke
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
_______________________________________________
m2t-dev mailing list
m2t-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2t-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf |
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490
|
