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
