Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?

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.vogel@xxxxxxxxxxx> 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 <tjwatson@xxxxxxxxxx> 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.vogel@xxxxxxxxxxx>
> Sent by: equinox-dev-bounces@eclipse.org
> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> 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.vogel@xxxxxxxxxxx, Web:
> http://www.vogella.com
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> 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.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

Back to the top