[equinox-dev] bundle resource URLs format has changed
The failure in org.eclipse.core.tests.runtime (org.eclipse.core.tests.internal.runtime.FileLocatorTest.testFileLocatorFind) is a result of the fix to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=252303 In this bug we changed the format of the bundle resource URLs to encode a framework instance id in the URLs host. The bundle resource URL hosts used to only include the ID of the bundle where the resource is located. Now the host includes a framework instance id encoded in the host (i.e. framewrok id.bundle id). We have always considered the scheme of the bundle resource URLs to be internal. The scheme is not specified by OSGi and the external format of the bundle resource URLs cannot be depended on from one framework to another framework implementation. I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262376 to fix the runtime tests. I am bringing this issue up to the community because others may have been making assumptions on the format of the bundle resource URLs. Let the Equinox team know if you find any other issues with this change. Thanks. Tom From: eclipse-rel...@eclipse.org To: platform-releng-...@eclipse.org Date: 01/26/2009 03:17 AM Subject:[platform-releng-dev] [eclipse-build]Build I20090125-2000 (Timestamp: 200901252000):Automated JUnit testing complete. Test failures/errors occurred. Build I20090125-2000 (Timestamp: 200901252000): Automated JUnit testing is complete. Test failures/errors occurred in the following: org.eclipse.ant.tests.core_linux.gtk.x86 org.eclipse.ant.tests.core_linux.gtk.x86_6.0 org.eclipse.ant.tests.core_macosx.carbon.ppc_5.0 org.eclipse.ant.tests.core_win32.win32.x86 org.eclipse.ant.tests.core_win32.win32.x86_6.0 org.eclipse.ant.tests.ui_linux.gtk.x86 org.eclipse.ant.tests.ui_linux.gtk.x86_6.0 org.eclipse.ant.tests.ui_macosx.carbon.ppc_5.0 org.eclipse.ant.tests.ui_win32.win32.x86 org.eclipse.ant.tests.ui_win32.win32.x86_6.0 org.eclipse.core.tests.runtime_linux.gtk.x86 org.eclipse.core.tests.runtime_linux.gtk.x86_6.0 org.eclipse.core.tests.runtime_macosx.carbon.ppc_5.0 org.eclipse.core.tests.runtime_win32.win32.x86 org.eclipse.core.tests.runtime_win32.win32.x86_6.0 org.eclipse.equinox.p2.tests_linux.gtk.x86 org.eclipse.equinox.p2.tests_linux.gtk.x86_6.0 org.eclipse.equinox.p2.tests_macosx.carbon.ppc_5.0 org.eclipse.equinox.p2.tests_win32.win32.x86 org.eclipse.equinox.p2.tests_win32.win32.x86_6.0 org.eclipse.jdt.debug.tests_linux.gtk.x86 org.eclipse.jdt.debug.tests_linux.gtk.x86_6.0 org.eclipse.jdt.debug.tests_macosx.carbon.ppc_5.0 org.eclipse.jdt.debug.tests_win32.win32.x86 org.eclipse.jdt.debug.tests_win32.win32.x86_6.0 org.eclipse.pde.ui.tests_macosx.carbon.ppc_5.0 org.eclipse.releng.tests_linux.gtk.x86 org.eclipse.releng.tests_linux.gtk.x86_6.0 org.eclipse.releng.tests_macosx.carbon.ppc_5.0 org.eclipse.releng.tests_win32.win32.x86 org.eclipse.releng.tests_win32.win32.x86_6.0 org.eclipse.swt.tests_linux.gtk.x86 org.eclipse.swt.tests_linux.gtk.x86_6.0 org.eclipse.ua.tests_linux.gtk.x86 org.eclipse.ua.tests_linux.gtk.x86_6.0 org.eclipse.ua.tests_macosx.carbon.ppc_5.0 org.eclipse.ua.tests_win32.win32.x86 org.eclipse.ua.tests_win32.win32.x86_6.0 org.eclipse.ui.tests.navigator_macosx.carbon.ppc_5.0 HTTP Download: http://download.eclipse.org/eclipse/downloads/drops/I20090125-2000 ___ platform-releng-dev mailing list platform-releng-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/platform-releng-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Adding Equinox Declarative Services (DS) to the Eclipse SDK
Howdy y'all. I like to raise the question of us adding Equinox DS to the Eclipse SDK. DS provides a powerful way to deal with OSGi services and in my opinion, greatly simplifies the development of services. As we forge towards Eclipse 3.5, we made a lot of steps to make DS easier to use in the Eclipse SDK without it actually being in the SDK: - Prosyst donated a high quality implementation of OSGi DS that made its way to the Equinox SDK - PDE release DS component authoring tools as part of a GSOC project and 3.5 work - The DS spec was updated to work better with lazy bundles ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575) Technically, to add DS to the Eclipse SDK all we need to do as add these two tiny bundles: org.eclipse.equinox.ds (.15MB) org.eclipse.equinox.util (.02MB) So my request in sending this email out is to get the opinion of consumers (anyone who builds applications on top of Eclipse) and producers (the Eclipse platform team, especially the Equinox committers). Do consumers see a benefit of having DS in the SDK? Does the greater Eclipse team feel comfortable with having DS in the SDK and may use it in the future potentially? And if we reach a consensus, it would be great to see DS included with the Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun discussion :) Thoughts? Cheers, Chris Aniszczyk ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK
+1 Actually, a few month ago I have filed a bug for adding DS to the Eclipse SDK, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=253926 Kai From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Chris Aniszczyk Sent: Montag, 26. Januar 2009 17:35 To: General development mailing list of the Eclipse project. Cc: Equinox development mailing list Subject: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK Howdy y'all. I like to raise the question of us adding Equinox DS to the Eclipse SDK. DS provides a powerful way to deal with OSGi services and in my opinion, greatly simplifies the development of services. As we forge towards Eclipse 3.5, we made a lot of steps to make DS easier to use in the Eclipse SDK without it actually being in the SDK: - Prosyst donated a high quality implementation of OSGi DS that made its way to the Equinox SDK - PDE release DS component authoring tools as part of a GSOC project and 3.5 work - The DS spec was updated to work better with lazy bundles (https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575) Technically, to add DS to the Eclipse SDK all we need to do as add these two tiny bundles: org.eclipse.equinox.ds (.15MB) org.eclipse.equinox.util (.02MB) So my request in sending this email out is to get the opinion of consumers (anyone who builds applications on top of Eclipse) and producers (the Eclipse platform team, especially the Equinox committers). Do consumers see a benefit of having DS in the SDK? Does the greater Eclipse team feel comfortable with having DS in the SDK and may use it in the future potentially? And if we reach a consensus, it would be great to see DS included with the Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun discussion :) Thoughts? Cheers, Chris Aniszczyk ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Adding Equinox Declarative Services (DS) to the Eclipse SDK
+1 However there are still issues related to the interoperability of extensions and services, due to the lifecycle mismatch. This is the case whether services are implemented using DS, or Spring-DM, or the good old fashioned way with spit and elbow grease Eclipse applications will be mostly based on extensions for the foreseeable future, so if we start to use services in any meaningful way then there will sooner or later (most likely sooner) be a need for the two models to interoperate more cleanly. Regards Neil On Mon, Jan 26, 2009 at 4:35 PM, Chris Aniszczyk z...@eclipsesource.com wrote: Howdy y'all. I like to raise the question of us adding Equinox DS to the Eclipse SDK. DS provides a powerful way to deal with OSGi services and in my opinion, greatly simplifies the development of services. As we forge towards Eclipse 3.5, we made a lot of steps to make DS easier to use in the Eclipse SDK without it actually being in the SDK: - Prosyst donated a high quality implementation of OSGi DS that made its way to the Equinox SDK - PDE release DS component authoring tools as part of a GSOC project and 3.5 work - The DS spec was updated to work better with lazy bundles (https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575) Technically, to add DS to the Eclipse SDK all we need to do as add these two tiny bundles: org.eclipse.equinox.ds (.15MB) org.eclipse.equinox.util (.02MB) So my request in sending this email out is to get the opinion of consumers (anyone who builds applications on top of Eclipse) and producers (the Eclipse platform team, especially the Equinox committers). Do consumers see a benefit of having DS in the SDK? Does the greater Eclipse team feel comfortable with having DS in the SDK and may use it in the future potentially? And if we reach a consensus, it would be great to see DS included with the Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun discussion :) Thoughts? Cheers, Chris Aniszczyk ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK
+1 -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Toedter, Kai kai.toed...@siemens.com To: Equinox development mailing list equinox-dev@eclipse.org, General development mailing list of the Eclipse project. eclipse-...@eclipse.org Date: 2009/01/26 11:46 Subject: RE: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK Sent by: equinox-dev-boun...@eclipse.org +1 Actually, a few month ago I have filed a bug for adding DS to the Eclipse SDK, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=253926 Kai From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Chris Aniszczyk Sent: Montag, 26. Januar 2009 17:35 To: General development mailing list of the Eclipse project. Cc: Equinox development mailing list Subject: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK Howdy y'all. I like to raise the question of us adding Equinox DS to the Eclipse SDK. DS provides a powerful way to deal with OSGi services and in my opinion, greatly simplifies the development of services. As we forge towards Eclipse 3.5, we made a lot of steps to make DS easier to use in the Eclipse SDK without it actually being in the SDK: - Prosyst donated a high quality implementation of OSGi DS that made its way to the Equinox SDK - PDE release DS component authoring tools as part of a GSOC project and 3.5 work - The DS spec was updated to work better with lazy bundles ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575) Technically, to add DS to the Eclipse SDK all we need to do as add these two tiny bundles: org.eclipse.equinox.ds (.15MB) org.eclipse.equinox.util (.02MB) So my request in sending this email out is to get the opinion of consumers (anyone who builds applications on top of Eclipse) and producers (the Eclipse platform team, especially the Equinox committers). Do consumers see a benefit of having DS in the SDK? Does the greater Eclipse team feel comfortable with having DS in the SDK and may use it in the future potentially? And if we reach a consensus, it would be great to see DS included with the Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun discussion :) Thoughts? Cheers, Chris Aniszczyk___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
