Re: [emf-dev] EMF interface instance access pattern

[Alexander Fedorov <alexander.fedorov@xxxxxxxxxx>]

Found it [1]!

Browsed the delta at [2], it does not look like an evil compatibility 
breaker.
The concept of adding "version" to resolve EPackage needs further 
discussions, for me "standardizing" NS URI format (with adding version 
string to it) looks more promising.
Other things may be resolved via extending GenModel and templates.

What is the current state of this effort regarding "OSGi-friendly" EMF?

[1] 
https://www.eclipsecon.org/2012/sites/eclipsecon.org.2012/files/3mf-infinity-and-beyond.pdf
[2] https://github.com/mbarbero/emf/compare/master...mbarbero:3mf

Regards,
AF

09.07.2019 13:11, Alexander Fedorov пишет:
> Thanks, this is exactly that I'm looking for!
> Unfortunately this link works extremelly slow for me and I still 
> unable to see the page.
>
> Probably you know some alternative URL?
>
> Thanks,
> AF
>
> 09.07.2019 12:58, Pierre-Charles David пишет:
> > On 09/07/2019 11:27, Alexander Fedorov wrote:
> > > Hello,
> >
> > Hi,
> >
> >
> > > In EMF runtime and generated code there is a "interface instance 
> > > access" pattern like:
> > >
> > >   public interface Registry
> > >   {
> > >     public static final Registry INSTANCE = new RegistryImpl();
> > >   }
> > >
> > > It is good and stable. It works perfect.
> > > However, it may look "too static" for OSGi-based approach where 
> > > interface should not reference its implementation.
> > >
> > > How would you implement it today for OSGi-oriented architecture 
> > > executed by 1.8+ Java? 
> >
> >
> > You might be interested in this presentation [1] from Mikael Barbero 
> > (presented at EclipseCon 2012), which tried to imagine what a more 
> > modern/dynamic/OSGi-compatible version of EMF could look like if 
> > backward compatibility was not an issue (it is). It tackled this 
> > particular issue, among others.
> >
> > Regards,
> > Pierre-Charles David
> >
> > [1] https://fr.slideshare.net/mikaelbarbero/3mf-infinityandbeyond
> >
> > _______________________________________________
> > emf-dev mailing list
> > emf-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/emf-dev
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/emf-dev