Eclipse Community Forums: Remote Application Platform (RAP) » Why using fragments in SingleSourcing

Help

Home

Home » Eclipse Projects » Remote Application Platform (RAP) » Why using fragments in SingleSourcing

Show: Today's Messages :: Show Polls :: Message Navigator

Why using fragments in SingleSourcing [message #119750]

Tue, 27 January 2009 08:50

Gunnar Wurl

Messages: 34
Registered: July 2009

Member

Hi,

I read an article [1] from Stefan Schäfer about SingleSourcing which I
found in your buzz section. He recommends using one host plug-in and
separate plug-ins for each platform. The host plug-in depends on the other
plugins and they export their classes. When using this approach the host
plug-in knows the classes of the other plug-ins. In your webinar you
recommended using fragments. I wanted to ask why you prefer using
fragments over plug-ins and where the advantage is.

Thanks

Gunnar

[1]
http://www.oio.de/public/opensource/eclipse-rap/tutorial-ecl ipse-rich-application-plattform-portierung.htm

Report message to a moderator

Re: Why using fragments in SingleSourcing [message #120082 is a reply to message #119750]

Thu, 29 January 2009 14:00

Benjamin Muskalla

Messages: 338
Registered: July 2009

Senior Member

Hi Gunnar,

Stefan describes two different approaches which are both bundle based.
a) Using a host bundle and two platform-specific (ps) bundles. The host
bundle has a package import which is resolved by an exported package for
both ps bundles. One big problem I see is that you have to keep both ps
bundles in sync with each other. The compiler will not help in this case
and the forgotten implementations for one of the platforms can then
cause trouble during the runtime.

b) Extension point approach: Host bundle provides extension point, ps
bundles provide extensions. In my eyes the extension point approach is
too heavyweight for the scenario. Keep in mind: creating an extension
point schema, using the extension registry to read the extensions,
looking up the class, initiating the provider class of the ps bundle.
And if you want to have a separation of concerns you have to do this for
every class. Even though extension points can be declared internal in
the meantime, clients of your bundle can see these extension points and
even contribute to them. And that is what extension points are for -
extending a bundle with additional use cases and not to have only one
contribution.

Don't get me wrong - all approaches have their pros and cons. Not even
the fragment idea is perfect ;-)

But let me give you an idea why we use fragments for doing single
sourcing. One idea is that the ps implementations are really part of the
host. And that's what fragments are for.
Another point is the classloader aspect. With a fragment you live in the
same classloader as your host bundle and have access to everything
(non-exported + package private stuff).
And in contrary to the first point mentioned above you have tooling
support. The compiler will tell you that the facade in your host bundle
is not correctly implemented in your fragment (same idea as the
extension point one but more lightweight).

I hope this helps a little bit to clarify the situation.

Cheers
Benny

Gunnar Wurl wrote:
> Hi,
>
> I read an article [1] from Stefan Schäfer about SingleSourcing which I
> found in your buzz section. He recommends using one host plug-in and
> separate plug-ins for each platform. The host plug-in depends on the
> other plugins and they export their classes. When using this approach
> the host plug-in knows the classes of the other plug-ins. In your
> webinar you recommended using fragments. I wanted to ask why you prefer
> using fragments over plug-ins and where the advantage is.
>
> Thanks
>
> Gunnar
>
>
> [1]
> http://www.oio.de/public/opensource/eclipse-rap/tutorial-ecl ipse-rich-application-plattform-portierung.htm
>
>

Report message to a moderator