Re: [equinox-dev] Profile for the running instance
I thought we already had this. The current profile was called "this" I think (or perhaps "self"). I recall adding the function when I did the provisioning helper etc. Jeff Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/27/2007 09:16 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject [equinox-dev] Profile for the running instance Hello, I just released code allowing access to the profile of the running system, aka self. To get it, simply query the profile registry with the special token SELF available from the IProfileRegistry interface. The value for self is derived from the value of the system property eclipse.prov.profile. If this system property is not set then agent starts "SELF" is unknown. PaScaL ___ 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
[equinox-dev] Equinox Summit reminder
As Labour (or Labor) Day looms on the horizon signalling the end of summer it is time to start planning that Fall travel schedule. What schedule would be complete without a trip to Ottawa at the end of September for the Equinox Summit? http://wiki.eclipse.org/Equinox_Summit_2007 The event is targetted at committers, contributors and heavy users of Equinox and related technologies (e.g., PDE). The two days of discussion will cover topics from classloading, OSGi and the runtime basics to server-side Eclipse, the new provisioning work (p2) and evolutions in PDE. Should be quite an interesting mix. Check out the wiki link (above) for more information on hotel and registration. See you there... Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
Along with the following bug fixes I updated every equinox project in the SDK with the new code formatter settings for Equinox. That is why so many projects have changed this build. The map file has been updated for the following Bug changes: + Bug 127963. ContextFinder caches classes from Class#forName (FIXED) + Bug 177007. Classes in boot classloader are not properly loaded for some Eclipse plugins (FIXED) + Bug 198423. [launcher] failed to load x86_64 library on win32.x86 when self-hosting (FIXED) + Bug 198447. FileLocator needs a helper method to get the location of a bundle (FIXED) + Bug 198525. HashCode problem in org.eclipse.osgi.framework.internal.core.BundleResourceHandler (FIXED) + Bug 198823. [launcher] eclipse.ini is not portable (NEW) + Bug 200231. [app] Support creating app container without app launcher (ASSIGNED) + Bug 200296. [NLS] NLS.bind crashed with NegativeArraySizeException when given empty format string and short parameter (FIXED) + Bug 200582. [Launcher] Shared Memory Leak (FIXED) + Bug 200596. Eclipse launcher (erroneously) fails to find its companion shared library when using relative directory with a forward slash and launch directory is in your PATH (on Windows) (NEW) + Bug 200604. [Launcher] Allow relative path for --launcher.library (FIXED) + Bug 200950. [launcher] Bad memory reference after failed shared memory (FIXED) + Bug 201255. NullPointerException occurs if a fragment attaches to an uninstalled bundle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.app org.eclipse.equinox.http.jetty org.eclipse.osgi.tests org.eclipse.equinox.http org.eclipse.osgi org.eclipse.equinox.metatype org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.device org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.http.servletbridge org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.http.registry org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.http.servlet org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.preferences org.eclipse.equinox.useradmin org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.event org.eclipse.equinox.jsp.jasper Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] Equinox provisioning has a name
During today's team meeting we have settled on a name for the "equinox provisioning". It is P2. Bundles and packages will be renamed just after M2 ships. PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Profile for the running instance
Hello, I just released code allowing access to the profile of the running system, aka self. To get it, simply query the profile registry with the special token SELF available from the IProfileRegistry interface. The value for self is derived from the value of the system property eclipse.prov.profile. If this system property is not set then agent starts "SELF" is unknown. PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] getResources : bundleresource
Erik, Either of your options should work. I prefer option 1 though :) Can you open a bug against Equinox->Framework and record your usecase in the bug report. We may need to consider using the port to indicate a classpath entry in the bundle instead of an entry into the list of duplicate resources. I think the OSGi spec is also vague in the area of bundle resource URLs. We may need to go back to OSGi and ask for clarification. Thanks. Tom Erik Bengtson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/27/2007 05:08 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] getResources : bundleresource Thomas, You got my use case, and answered very well :). my bundles are deployed as inner libraries. Two options I know to solve my issue: 1) use bundles as real bundles :) 2) use FileLocator.resolve() to resolve the URL and load MANIFEST.MF files from there. If you have more options, I would appreciate. Thanks, Erik Bengtson Quoting Thomas Watson <[EMAIL PROTECTED]>: > I'm a bit confused by the usecase. Are these real bundles or just inner > jars which you use as inner libraries? If they are real bundles then why > don't you install them as real bundles instead? > > The bundleresource protocol uses the port as an index into the list of > resources of a given name (e.g plugin.xml). In your case it sounds like > you have more resources named META-INF/MANIFEST.MF in your bundle than you > do plugin.xml so the two lists and indexes do not match up. For example, > imagine you have a bundle which has jars A, B, C, D which all have > META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call > to classloader.getResources("plugin.xml") gives you something like this: > > bundleresource://26:0/plugin.xml (C) > bundleresource://26:1/plugin.xml (D) > > A call to classloader.getResources("META-INF/MANIFEST.MF") gives you > something like this: > > bundleresource://26:0/META-INF/MANIFEST.MF (base bundle) > bundleresource://26:1/META-INF/MANIFEST.MF (A) > bundleresource://26:2/META-INF/MANIFEST.MF (B) > bundleresource://26:3/META-INF/MANIFEST.MF (C) > bundleresource://26:4/META-INF/MANIFEST.MF (D) > > As you can see the resource indexes will not match for the two different > resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D. > > Tom > > > > > Erik Bengtson <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 08/27/2007 01:58 PM > Please respond to > Equinox development mailing list > > > To > Equinox development mailing list > cc > > Subject > [equinox-dev] getResources : bundleresource > > > > > > > Hi, > > I have some bundles (B,C,D) that are not deployed as osgi bundles, but as > libraries within a bundle (A). > > In bundle A, I have a custom internal registry of the plugin.xml from > files > (B,C,D). > > 1) find and load all plugin.xml files using classloader.getResources() > > I get an enumeration of: > > bundleresource://26:3/plugin.xml (D) > bundleresource://26:2/plugin.xml (C) > bundleresource://26:1/plugin.xml (B) > > So far so good, but now I have to load the corresponding > /META-INF/MANIFEST.MF > files from each bundle (B,C,D). > > 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF"); > > My problem is that it returns the MANIFEST.MF from bundle (C), instead of > bundle > (D). > > What am I doing wrong? > > Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible > and > uses Eclipse Extension/Extension Points for declarative services. I have > an > internal registry of bundles/extension/extension points when running > outside an > osgi container. > > Regards, > > Erik Bengtson > http://jpox.org > ___ > 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] getResources : bundleresource
Thomas, You got my use case, and answered very well :). my bundles are deployed as inner libraries. Two options I know to solve my issue: 1) use bundles as real bundles :) 2) use FileLocator.resolve() to resolve the URL and load MANIFEST.MF files from there. If you have more options, I would appreciate. Thanks, Erik Bengtson Quoting Thomas Watson <[EMAIL PROTECTED]>: > I'm a bit confused by the usecase. Are these real bundles or just inner > jars which you use as inner libraries? If they are real bundles then why > don't you install them as real bundles instead? > > The bundleresource protocol uses the port as an index into the list of > resources of a given name (e.g plugin.xml). In your case it sounds like > you have more resources named META-INF/MANIFEST.MF in your bundle than you > do plugin.xml so the two lists and indexes do not match up. For example, > imagine you have a bundle which has jars A, B, C, D which all have > META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call > to classloader.getResources("plugin.xml") gives you something like this: > > bundleresource://26:0/plugin.xml (C) > bundleresource://26:1/plugin.xml (D) > > A call to classloader.getResources("META-INF/MANIFEST.MF") gives you > something like this: > > bundleresource://26:0/META-INF/MANIFEST.MF (base bundle) > bundleresource://26:1/META-INF/MANIFEST.MF (A) > bundleresource://26:2/META-INF/MANIFEST.MF (B) > bundleresource://26:3/META-INF/MANIFEST.MF (C) > bundleresource://26:4/META-INF/MANIFEST.MF (D) > > As you can see the resource indexes will not match for the two different > resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D. > > Tom > > > > > Erik Bengtson <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 08/27/2007 01:58 PM > Please respond to > Equinox development mailing list > > > To > Equinox development mailing list > cc > > Subject > [equinox-dev] getResources : bundleresource > > > > > > > Hi, > > I have some bundles (B,C,D) that are not deployed as osgi bundles, but as > libraries within a bundle (A). > > In bundle A, I have a custom internal registry of the plugin.xml from > files > (B,C,D). > > 1) find and load all plugin.xml files using classloader.getResources() > > I get an enumeration of: > > bundleresource://26:3/plugin.xml (D) > bundleresource://26:2/plugin.xml (C) > bundleresource://26:1/plugin.xml (B) > > So far so good, but now I have to load the corresponding > /META-INF/MANIFEST.MF > files from each bundle (B,C,D). > > 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF"); > > My problem is that it returns the MANIFEST.MF from bundle (C), instead of > bundle > (D). > > What am I doing wrong? > > Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible > and > uses Eclipse Extension/Extension Points for declarative services. I have > an > internal registry of bundles/extension/extension points when running > outside an > osgi container. > > Regards, > > Erik Bengtson > http://jpox.org > ___ > 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] getResources : bundleresource
I'm a bit confused by the usecase. Are these real bundles or just inner jars which you use as inner libraries? If they are real bundles then why don't you install them as real bundles instead? The bundleresource protocol uses the port as an index into the list of resources of a given name (e.g plugin.xml). In your case it sounds like you have more resources named META-INF/MANIFEST.MF in your bundle than you do plugin.xml so the two lists and indexes do not match up. For example, imagine you have a bundle which has jars A, B, C, D which all have META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call to classloader.getResources("plugin.xml") gives you something like this: bundleresource://26:0/plugin.xml (C) bundleresource://26:1/plugin.xml (D) A call to classloader.getResources("META-INF/MANIFEST.MF") gives you something like this: bundleresource://26:0/META-INF/MANIFEST.MF (base bundle) bundleresource://26:1/META-INF/MANIFEST.MF (A) bundleresource://26:2/META-INF/MANIFEST.MF (B) bundleresource://26:3/META-INF/MANIFEST.MF (C) bundleresource://26:4/META-INF/MANIFEST.MF (D) As you can see the resource indexes will not match for the two different resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D. Tom Erik Bengtson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/27/2007 01:58 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject [equinox-dev] getResources : bundleresource Hi, I have some bundles (B,C,D) that are not deployed as osgi bundles, but as libraries within a bundle (A). In bundle A, I have a custom internal registry of the plugin.xml from files (B,C,D). 1) find and load all plugin.xml files using classloader.getResources() I get an enumeration of: bundleresource://26:3/plugin.xml (D) bundleresource://26:2/plugin.xml (C) bundleresource://26:1/plugin.xml (B) So far so good, but now I have to load the corresponding /META-INF/MANIFEST.MF files from each bundle (B,C,D). 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF"); My problem is that it returns the MANIFEST.MF from bundle (C), instead of bundle (D). What am I doing wrong? Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible and uses Eclipse Extension/Extension Points for declarative services. I have an internal registry of bundles/extension/extension points when running outside an osgi container. Regards, Erik Bengtson http://jpox.org ___ 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
[equinox-dev] getResources : bundleresource
Hi, I have some bundles (B,C,D) that are not deployed as osgi bundles, but as libraries within a bundle (A). In bundle A, I have a custom internal registry of the plugin.xml from files (B,C,D). 1) find and load all plugin.xml files using classloader.getResources() I get an enumeration of: bundleresource://26:3/plugin.xml (D) bundleresource://26:2/plugin.xml (C) bundleresource://26:1/plugin.xml (B) So far so good, but now I have to load the corresponding /META-INF/MANIFEST.MF files from each bundle (B,C,D). 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF"); My problem is that it returns the MANIFEST.MF from bundle (C), instead of bundle (D). What am I doing wrong? Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible and uses Eclipse Extension/Extension Points for declarative services. I have an internal registry of bundles/extension/extension points when running outside an osgi container. Regards, Erik Bengtson http://jpox.org ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] questions about equinox
Arash, You might try the news group eclipse.technology.equinox on the news.eclipse.org server. This is a very active list for users of equinox. Hope that helps. -Brett Humphreys -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arash Amiri Sent: Monday, August 27, 2007 5:42 AM To: Equinox development mailing list Subject: [equinox-dev] questions about equinox Hi folks! Is this the right list to ask questions about equinox oor is there also a "users list" for equinox? cheers, arash ___ 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] questions about equinox
Arash Amiri wrote: Hi folks! Is this the right list to ask questions about equinox oor is there also a "users list" for equinox? Yeap there is. Check here http://www.eclipse.org/newsgroups/ and join eclipse.technology.equinox group. cheers, arash ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev Thx, Aggelos Mpimpoudis -- Dept. of Informatics & Telecommunications, University of Athens Athens, Greece Gsm: +30 6942075153 / Skype: aggelos.mpimpoudis a.mpimpoydhs [at] di.uoa.grhttp://www.di.uoa.gr/~std03092/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] questions about equinox
Hi folks! Is this the right list to ask questions about equinox oor is there also a "users list" for equinox? cheers, arash ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev