Re: [p2-dev] @noimplement on IMetadataRepository ?

[Marcus R Kestler <marcus.kestler@xxxxxxxxxx>]

A typical approach used in other plugins is to add Ex versions. Your new functionality is implemented in IMetadataRepositoryEx, and any clients who depend on new methods that bind to that interface.
This gets a little strange over time, as you end up with multiple ex versions. I think it is better to name them based on functionality.
In any case it allows your clients to implement the interfaces, and allows your API to progress.
---------------------------------------------
Marcus Kestler
IBM Rational Capilano Group
---------------------------------------------

Ed Merks ---02/16/2010 08:07:04 AM---John, EMF has the same issue about subclassing EObject/InternalEObject rather

From:	Ed Merks <ed.merks@xxxxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	02/16/2010 08:07 AM
Subject:	Re: [p2-dev] @noimplement on IMetadataRepository ?
Sent by:	p2-dev-bounces@xxxxxxxxxxx

---

John,

EMF has the same issue about subclassing EObject/InternalEObject rather than extending the base class, i.e., BasicEObjectImpl or one of its derivatives. Yes, it's a harsh limitation, one we share with IMetaDataRepository and the other Eclipse APIs to which you refer. Of course we could change the generator effectively to copy BasicEObjectImpl into some other class we extend, but that still leaves the client with a copy rather than a reusable base we can modify in the future. In any case, we must realize that an abstract base isn't a panacea for API migration given it's not always possible for an abstract base to implement fully whatever new thing is added to the API, e.g., the EObject.eInvoke API that was added this release.

Cheers,
Ed


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
 _______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev