Peter we also have a similar separate API. Our reason however is because we deliberately needed to segregate ourselves from the OSGi API that might be in our host environment (which might be an osgi runtime itself).
So having a separate API which is a wrapper for, but distinct from, OSGi service layer has other values. For one it's easier to map legacy code onto services without actually brining in OSGi, which goes directly at what the OSGi Alliance refers to "services first" migration to OSGi. Sincerely, - Ray On Tue, May 24, 2016 at 10:20 AM, Scott Lewis <sle...@composent.com> wrote: > On 5/23/2016 11:25 PM, Peter Kriens wrote: > >> Interesting! Another service fan :-) >> > > Indeed. > > >> One thing, why create a special API for this? >> > > Because I believe it's clearer and therefore easier for non-OSGi (java) > programmers to consume...relative to either the embedded framework or > Connect. > > Scott > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
