3 Mar 09:50
3 Mar 16:35
Re: Implementation for Foreign App Admin.?
The Equinox application container, which is implemented in the org.eclipse.equinox.app bundle, is a container for running Eclipse applications which are defined by the org.eclipse.core.runtime.applications extension point. This application container is not considered a Foreign application container because Eclipse applications are defined in real OSGi bundles and integrate fully into the OSGi environment (e.g. they can have a BundleActivator, export packages, use services etc.). Currently we do not have any examples of a Foreign application container in Equinox.
Tom
"Srijith Kochunni" ---03/03/2008 02:46:04 AM---Hi All,
|
From: |
"Srijith Kochunni" <ksrijith-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> |
|
To: |
<equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> |
|
Date: |
03/03/2008 02:46 AM |
|
Subject: |
[equinox-dev] Implementation for Foreign App Admin.? |
Hi All,
Is there an equinox implementation for Foreign Application Admin Service as defined in the OSGi specification.
I went through the eclipse OSGi downloads section, but could not find anything related.
Thanks,
Srijith.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
3 Mar 20:31
[prov] Changed repository version numbers
We made a number of breaking changes to p2 metadata and artifact repository formats last week in preparation for integration with the platform. Attempting to use old repositories sometimes appears to work but can fail in strange ways. To avoid these subtle problems as we migrate into the platform, I have just released a fix to HEAD that increments the repository version numbers. When you get tomorrow's build, you will no longer be able to load the old repositories. If you are running with p2 from HEAD today, you will need to rebuild your own repositories. From this point on, we will strive to maintain compatibility of the repository file formats. For details see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=221178.
John
3 Mar 22:09
j9 class sharing and CL.getResource
Hi! I have a question regarding J9 class sharing and the adaptor hooks: I have an adaptor hook that uses specialized bundle file objects to delegate to the j9 class sharing. This implementation is done for all path parameters that end with ".class". Now a library that I use calls CL.getResource for a class file to get the bytecode of that class. In the case of j9 class sharing this call returns just some identifier used by j9 class sharing instead of the real bytecode. Did you observe similar problems with j9 class sharing? Do you have any idea how to solve this? Thanks for your help!!! Best regards, -Martin
4 Mar 01:36
Re: j9 class sharing and CL.getResource
I have experienced similar issues, both with a shared classes adaptor and a jxe adaptor on j9. In both cases the issue can be worked around by doing different things with the BundleEntry#getBytes() and BundleEntry#getInputStream methods. The getBytes() method is only used by the classloader to get the byte[] to define the class. This is where the "magic bytes" with the identifier used by j9 class sharing should be returned. The getInputStream is used by the URLs CL.getResource. In your adaptor you can implement getInputStream to read the real bytes out of the content of the bundle instead of using the shared classes cache bytes. This should allow you to get the real bytes of the class file.
HTH.
Tom
Martin Lippert ---03/03/2008 03:09:58 PM---Hi!
|
From: |
Martin Lippert <lippert-HInyCGIudOg@public.gmane.org> |
|
To: |
Equinox Project <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org> |
|
Date: |
03/03/2008 03:09 PM |
|
Subject: |
[equinox-dev] j9 class sharing and CL.getResource |
Hi!
I have a question regarding J9 class sharing and the adaptor hooks: I
have an adaptor hook that uses specialized bundle file objects to
delegate to the j9 class sharing. This implementation is done for all
path parameters that end with ".class".
Now a library that I use calls CL.getResource for a class file to get
the bytecode of that class. In the case of j9 class sharing this call
returns just some identifier used by j9 class sharing instead of the
real bytecode.
Did you observe similar problems with j9 class sharing? Do you have any
idea how to solve this?
Thanks for your help!!!
Best regards,
-Martin
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
4 Mar 01:41
programmatically recognizing that a file is a bundle?
I have a user workflow where I want to treat a jar file that is a bundle differently than I treat a jar file that is just some archive of stuff.
Is there a definitive way that I should programmatically examine a jar file and decide "this is a bundle."
I thought this would be relatively easy to find, but it wasn't obvious to me. If there's code to steal, can someone point me to it?
Simon suggested I might crack it open and look in the manifest header for the Bundle-SymbolicName.
I was hoping there was something more definitive, like, try to create a bundle from a file and it will throw some exception if it's not a bundle. 
susan
4 Mar 02:04
Re: programmatically recognizing that a file is a bundle?
Reading the manifest is unfortunately the only way to identify a bundle. If you were to try to install it, then more trouble would occurIf you can not depend on the p2 metadata generator, you can still get inspiration from the BundleDescriptionFactory#getBundleDescription(File) HTH, PaScaL From: Susan Franklin McCourt <susan_franklin@...> To: equinox-dev@... Date: 03/03/2008 07:46 PM Subject: [equinox-dev] programmatically recognizing that a file is a bundle? I have a user workflow where I want to treat a jar file that is a bundle differently than I treat a jar file that is just some archive of stuff. Is there a definitive way that I should programmatically examine a jar file and decide "this is a bundle." I thought this would be relatively easy to find, but it wasn't obvious to me. If there's code to steal, can someone point me to it? Simon suggested I might crack it open and look in the manifest header for the Bundle-SymbolicName. I was hoping there was something more definitive, like, try to create a bundle from a file and it will throw some exception if it's not a bundle.
4 Mar 03:16
Equinox projects tagged for the I-Build.
The map file has been updated for the following Bug changes:
+ Bug 128531. Set startlevel back to previous level when relaunched from console (FIXED)
+ Bug 215796. Request for including additional packages in org.eclipse.equinox.supplement (FIXED)
+ Bug 220251. [launcher] The org.eclipse.equinox.launcher platform-specific fragments are inconsistently marked as singletons (FIXED)
+ Bug 220397. [equinox.util] uses System.setProperty, not available on min EE (FIXED)
+ Bug 220681. Bad message when service object is not instanceof interface (FIXED)
+ Bug 220687. Extension registry does not update with new contents (FIXED)
+ Bug 220817. mozilla detection can detect invalid app (FIXED)
The following projects have changed:
org.eclipse.equinox.launcher.win32.win32.ia64
org.eclipse.equinox.launcher.carbon.macosx
org.eclipse.equinox.launcher.gtk.linux.s390x
org.eclipse.equinox.app
org.eclipse.equinox.http.jetty
org.eclipse.osgi
org.eclipse.equinox.launcher.motif.hpux.ia64_32
org.eclipse.equinox.launcher
org.eclipse.equinox.log
org.eclipse.equinox.launcher.gtk.solaris.sparc
org.eclipse.equinox.jsp.jasper.registry
org.eclipse.equinox.launcher.motif.aix.ppc
org.eclipse.equinox.device
org.eclipse.equinox.util
org.eclipse.equinox.launcher.gtk.linux.s390
org.eclipse.equinox.launcher.win32.win32.x86_64
org.eclipse.equinox.launcher.gtk.linux.ppc
org.eclipse.equinox.launcher.motif.linux.x86
org.eclipse.equinox.http.registry
org.eclipse.equinox.launcher.gtk.linux.x86_64
org.eclipse.equinox.launcher.motif.hpux.PA_RISC
org.eclipse.equinox.executable
org.eclipse.osgi.util
org.eclipse.equinox.supplement
org.eclipse.equinox.launcher.gtk.linux.x86
Tom
4 Mar 05:02
[prov] p2 contribution
The map file has been updated for the following Bug changes: + Bug 220605. IMetadataRepositoryManager will only load an old style update site if "site.xml" is part of the URL (NEW) + Bug 221256. [um] paths to site in platform are not relativized (FIXED) The following projects have changed: org.eclipse.equinox.p2.reconciler.dropins org.eclipse.equinox.p2.artifact.repository org.eclipse.equinox.p2.touchpoint.eclipse org.eclipse.equinox.p2.updatesite org.eclipse.equinox.p2.metadata.repository
4 Mar 13:20
Tagged p2 files for build.
The map file has been updated for the following Bug changes: + Bug 204209. [prov] Generated repo directory names don't match what colocated repo UI assumes (FIXED) + Bug 211102. [repo] [ui] IMetadataRepositoryManager URL validation (FIXED) + Bug 216911. [prov] Should IU's have multiple licenses (NEW) + Bug 217001. [prov] [ui] [metadata] can IU license and copyright properties be URLs? (FIXED) + Bug 217927. [prov] [ui] Update provisioning plan should be computed before showing popup (FIXED) + Bug 218451. [prov] Rename API packages to provisional API (FIXED) + Bug 218874. [prov] VM arguments should be in config.ini (FIXED) + Bug 220434. UpdateSiteMetadataRepository writes tracing info to System.out (FIXED) + Bug 220793. Optional inclusion of default feature CU (FIXED) + Bug 220814. Prompted for restart before anything is installed (FIXED) + Bug 220872. Many (many) attempts to read from the same invalid artifact repository (FIXED) + Bug 221254. Problems with dropins on second start (FIXED) The following projects have changed: org.eclipse.equinox.p2.metadata.repository org.eclipse.equinox.p2.engine org.eclipse.equinox.p2.updatesite org.eclipse.equinox.p2.touchpoint.eclipse org.eclipse.equinox.p2.metadata.generator org.eclipse.equinox.p2.artifact.repository org.eclipse.equinox.p2.reconciler.dropins org.eclipse.equinox.p2.directorywatcher org.eclipse.equinox.p2.ui org.eclipse.equinox.p2.user.ui.feature
RSS Feed