[equinox-dev] ECF consuming org.osgi.services.cm and org.osgi.service.metatype
Hi, the ECF team plans [1][2] to leverage org.osgi.services.cm and org.osgi.service.metatype with its discovery API and we're anxious to get comments from the Equinox team. Especially for #217981 which might be solved by combining efforts and on the issue of configuration admin still being in incubation/marked as red on the Equinox page. Do you plan on graduating cm with Ganymede? Cheers, Markus [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217981 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217978 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ECF consuming org.osgi.services.cm and org.osgi.service.metatype
We just had the graduation review for cm last week and are in the process of getting the code moved into the Equinox-Bundles project. A graduated cm bundle will be ready in M6. Tom From: Markus Alexander Kuppe [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/06/2008 07:00 AM Subject:[equinox-dev] ECF consuming org.osgi.services.cm and org.osgi.service.metatype Hi, the ECF team plans [1][2] to leverage org.osgi.services.cm and org.osgi.service.metatype with its discovery API and we're anxious to get comments from the Equinox team. Especially for #217981 which might be solved by combining efforts and on the issue of configuration admin still being in incubation/marked as red on the Equinox page. Do you plan on graduating cm with Ganymede? Cheers, Markus [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217981 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217978 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Signed bundles
The option to enable signed bundles in 3.3 is osgi.support.signature.verify (notice support and signature are reversed). In 3.4 we are introducing a more general option called osgi.signedcontent.support which does not have simple true|false options, but we will continue to recognize the old 3.3. option. Matt is documenting the security options in https://bugs.eclipse.org/bugs/show_bug.cgi?id=217765 The internal security manager class is needed to fully support postponed conditions in ConditionalPermissionAdmin. If postponed conditions are not needed then simply enabling the security manager with -Djava.security.policy= will enable the built-in security manager which will satisfy most needs. There is an option called eclipse.security. This option is used by the launcher jar to setup a policy to grant the framework and the launcher AllPermissions and specify the security manager to use. Unfortunately this still requires a reference to an internal class if you want to load a security manager to support postponed conditions. I've opened a bug to investigate making this easier. Perhaps eclipse.security manager can have a value that indicates the framework should load its internal security manager. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=218001. Tom From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/06/2008 07:47 AM Subject:Re: [equinox-dev] Signed bundles Marcel Offermans wrote: So, reiterating, if I want to run Equinox with OSGi security enabled and have it use my own keystore, I have to start it like this (formatted a bit for clarity, but typed as one big line): java -Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager -Djava.security.policy=policy -Dosgi.framework.keystore=keystore -Dosgi.signature.support.verify=true -jar org.eclipse.osgi_3.4.0.v20071207.jar -console -consoleLog Basically, I'm asking how Equinox is being run to be compliant with OSGi security. Is the above line accurate? Seems complicated and requires people to reference internal classes etc. Could be wrong but I remember it being simipler Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] EclipseCon installers
D'oh. What I'm looking for here is avoiding having M x N physical installer downloads (where M = # of platforms and N = # of packages). I don't expect us to make things more complicated or do more work, just working through the best possible structure given what we have now. Thanks Jeff John Arthorne wrote: I believe we need a different installer per platform (os/ws/arch), since they will have different launchers, unless there is some known way to bundle a standalone RCP application that will run on any platform. As for EPP packages, the installer works by reading an install description file that specifies what to install, where to get the bits from, etc. The description file is passed to the installer as a system property on the command line, or in the installer.ini file. Since each EPP package will just be represented by a different install description file, one could imagine a single installer with a series of scripts/batch files that pass in a different property for the description file. On the other hand, the installer is currently ~4MB (of which 2MB is SWT), so for simplicity having a separate installer per EPP per platform could also work. John *Jeff McAffer [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 02/04/2008 01:13 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] [prov] EclipseCon installers I forgot to ask during the call. Can we have one installer per EPP package? That is, one installer that would work for multiple platforms or do we have to have one installer for per EPP per platform? Jeff ___ 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
[equinox-dev] [launcher]
By using the -showsplash I can get an early splash screen. However when not using this mechanism we were able to set osgi.splashPath with a comma separated list of URLs. We still need the splash selection based on nl that we got when using osgi.splashPath. How can we get the splashpath bmp refreshed after early startup? The default behavior seems to be to continue using the early splash screen.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [launcher] Showsplash
James, The native code that is showing the early splash screen does not have support to change the bitmap that is being shown. This means that you need to wait until swt is available before it can be refreshed. With SWT I believe changing the image is just setting the BackgroundImage on the shell. The simplest way of contributing SWT to the splash screen is to use the workbench org.eclipse.ui.splashHandlers extension point and extend the EclipseSplashHandler class. The only problem is that the code that handles the osgi.splashPath and searches for NL variants (Main.getSplashLocation Main.searchForSplash) is not available available outside of Main. You will probably have to do that search yourself. -Andrew James D Miles [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/06/2008 11:01 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [launcher] By using the -showsplash I can get an early splash screen. However when not using this mechanism we were able to set osgi.splashPath with a comma separated list of URLs. We still need the splash selection based on nl that we got when using osgi.splashPath. How can we get the splashpath bmp refreshed after early startup? The default behavior seems to be to continue using the early splash screen. ___ 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 BoF for EclipseCon
Tom and I just submitted an Equinox BoF proposal for EclipseCon. https://eclipsecon.greenmeetingsystems.com/submissions/view/579 Hope to see you there. Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
