Hi John,
I actually just recently discovered the EMF changed EObject from being
an abstract class to being an interface. They had this harsh limitation
for the same reason as p2 I guess. To allow compatible API evolution :-)
How do we get rid of all the "Illegally implements" warnings in the p2
code?
Regards,
Thomas Hallgren
On 02/16/2010 04:49 PM, John Arthorne wrote:
Yes, clients are supposed to subclass
AbstractMetadataRepository rather than implementing the interface
directly. The restriction is there so that we can add methods to this
interface in the future - an interface implemented directly by clients
can never be evolved in a compatible way. This sounds like quite a
harsh limitation of EMF - many Eclipse APIs are moving towards abstract
base classes rather than interfaces to allow for compatible API
evolution.
John
On Mon, Feb 8, 2010 at 8:34 AM, Thomas
Hallgren <thomas@xxxxxxx> wrote:
Hi,
Why is the IMetadataRepository interface annotated with a
@noimplement? Not only do we get warnings all over the p2 code, I also
wonder what I I am supposed to do if I really want to write a
IMetadataRepository of my own. Our Aggregator already has one (backed
by an ecore model) and we might want to write others that are backed by
databases etc.
Are clients supposed to derive the AbstractMetadataRepository? For us,
that's problematic since we need to inherit the EObject from ecore. Or
are there other reasons for this annotation?
Regards,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|