There is fierce debate raging around this topic ever since I've been around
OSGi.

I would recommend putting your opinions forth on the public OSGi bugzilla
tracker https://osgi.org/bugzilla/

Sincerely,
- Ray

On Thu, Jul 5, 2018 at 11:00 AM, Lars Vogel <lars.vo...@vogella.com> wrote:

> Thanks, Todor and Tom.
>
> @Tom, IMHO obsolete API is sufficient to provide newer API. Tools like
> Sonar will flag this usage as an issue.
>
> Would be nice to have API which does not result in Sonar warnings.
>
> Maybe no need to deprecate the old OSGI API but also add a comment
> that it is obsolete once the new API is available? ;-)
>
> Best regards, Lars
>
>
>
> On Fri, Jun 29, 2018 at 3:43 PM, Thomas Watson <tjwat...@us.ibm.com>
> wrote:
> > Dictionary my be documented as obsolete, but it is not deprecated.  I
> would
> > not want to deprecate a spec'ed API method that takes non-deprecated
> types.
> > Anyway, the discussion is happening now in the expert group.
> >
> > Tom
> >
> >
> >
> >
> > ----- Original message -----
> > From: Lars Vogel <lars.vo...@vogella.com>
> > Sent by: equinox-dev-boun...@eclipse.org
> > To: Equinox development mailing list <equinox-dev@eclipse.org>
> > Cc:
> > Subject: [equinox-dev] Provide new OSGi service API without obsolete API
> > (Dictionary)?
> > Date: Fri, Jun 29, 2018 2:35 AM
> >
> > Hi,
> >
> > I wanted to give official feedback that my customers are surprised
> > that OSGi service API is based on obsolete data types.
> >
> > From the Javadoc of Dictionary:
> > ----
> > NOTE: This class is obsolete.
> > ----
> >
> > This makes the OSGi service API look outdated for several of the
> > customers I discussed this. OSGi ds hides this a bit but sometimes the
> > low-level API must be used.
> >
> > So for those involved in the OSGi spec, maybe you can consider
> > deprecating the old methods in BundleContext and providing new ones
> > with non-obsolete API, e.g., Map?
> >
> > I'm aware that this is "just a mailing list" but AFAIK several of the
> > subscribed people here are involved in the OSGi specification.
> >
> > Best regards, Lars
> >
> > --
> > Eclipse Platform project co-lead
> > CEO vogella GmbH
> >
> > Haindaalwisch 17a, 22395 Hamburg
> > Amtsgericht Hamburg: HRB 127058
> > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> > USt-IdNr.: DE284122352
> > Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> > http://www.vogella.com
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@eclipse.org
> > To change your delivery options, retrieve your password, or unsubscribe
> from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@eclipse.org
> > To change your delivery options, retrieve your password, or unsubscribe
> from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> --
> Eclipse Platform project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-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)
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to