Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?
Peter, I have not forgotten :) Sincerely, - Ray On Thu, Jul 5, 2018 at 1:07 PM, Peter Kriens wrote: > Fierce > > Men, you guys must really have forgotten me! :-) > > P > > > On 5 Jul 2018, at 17:39, Raymond Auge wrote: > > 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 > 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 >> 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 >> > Sent by: equinox-dev-boun...@eclipse.org >> > To: Equinox development mailing list >> > 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://os
Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?
Fierce Men, you guys must really have forgotten me! :-) P > On 5 Jul 2018, at 17:39, Raymond Auge wrote: > > 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/ <https://osgi.org/bugzilla/> > > Sincerely, > - Ray > > On Thu, Jul 5, 2018 at 11:00 AM, Lars Vogel <mailto: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 <mailto: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 mailto:lars.vo...@vogella.com>> > > Sent by: equinox-dev-boun...@eclipse.org > > <mailto:equinox-dev-boun...@eclipse.org> > > To: Equinox development mailing list > <mailto: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 > > <mailto:lars.vo...@vogella.com>, Web: > > http://www.vogella.com <http://www.vogella.com/> > > ___ > > equinox-dev mailing list > > equinox-dev@eclipse.org <mailto: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 > > <https://dev.eclipse.org/mailman/listinfo/equinox-dev> > > > > > > > > > > ___ > > equinox-dev mailing list > > equinox-dev@eclipse.org <mailto: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 > > <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 > <mailto:lars.vo...@vogella.com>, Web: http://www.vogella.com > <http://www.vogella.com/> > ___ > equinox-dev mailing list > equinox-dev@eclipse.org <mailto: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 > <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 ___ 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
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 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 > 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 > > Sent by: equinox-dev-boun...@eclipse.org > > To: Equinox development mailing list > > 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
Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?
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 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 > Sent by: equinox-dev-boun...@eclipse.org > To: Equinox development mailing list > 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
Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?
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 Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list 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 surprisedthat 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 thecustomers I discussed this. OSGi ds hides this a bit but sometimes thelow-level API must be used.So for those involved in the OSGi spec, maybe you can considerdeprecating the old methods in BundleContext and providing new oneswith non-obsolete API, e.g., Map?I'm aware that this is "just a mailing list" but AFAIK several of thesubscribed people here are involved in the OSGi specification.Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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
[equinox-dev] Provide new OSGi service API without obsolete API (Dictionary)?
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
