On Fri, Aug 7, 2009 at 2:58 PM, Richard S. Hall<[email protected]> wrote: > On 8/7/09 9:27, David Savage wrote: >> >> On Fri, Aug 7, 2009 at 2:04 PM, Richard S. Hall<[email protected]> >> wrote: >> >>> >>> On 8/7/09 4:44, David Savage wrote: >>> >>>> >>>> So the idea is to create an Eclipse PDE Framework Launcher hooked into >>>> the Sigil project model that uses the RFC 132 launching api vs a >>>> framework specific mechanism. This would allow sigil to launch any >>>> OSGi framework from this common API. There are some gotcha's here >>>> though - it looks like the equinox 3.5 release and the spec didn't >>>> quite meet - so from my testing so far it looks like equinox is >>>> expecting some framework specific headers that aren't in the spec :-s. >>>> I haven't yet tried the equinox trunk so perhaps this is fixed by now? >>>> >>>> >>> >>> Really? Like what? I have used a common launcher to launch both Equinox >>> and >>> Felix...it was a simple launcher, but it worked. >>> >> >> So I'm seeing the following error message: >> >> Exception in thread "main" java.lang.IllegalArgumentException: Cannot >> start without the following system properties set: osgi.framework, >> osgi.install.area >> at >> org.eclipse.osgi.framework.internal.core.FrameworkProperties.initializeProperties(FrameworkProperties.java:120) >> at >> org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalInit(EquinoxLauncher.java:65) >> at >> org.eclipse.osgi.framework.internal.core.EquinoxLauncher.init(EquinoxLauncher.java:38) >> at org.eclipse.osgi.launch.Equinox.init(Equinox.java:89) >> at org.apache.felix.sigil.common.runtime.Main.main(Main.java:47) >> >> This is when using org.eclipse.osgi_3.5.100.v20090629.jar which I >> resolve from the spring bundle repository - I guess there's the added >> possibility that the bundle in the spring repository is not the latest >> 3.5 from eclipse? >> > > I am told that this is a very early build of Equinox 3.6, so it doesn't > sound like it is a good one to use. > > From what I am told, Equinox assumes it is loaded from a class loader with a > protection domain that provides CodeSource objects, e.g., URLClassLoader, so > it may be failing depending on how you are loading its framework classes. > The other workaround is to set osgi.framework to a file: URL that points to > the org.eclipse.osgi jar and osgi.install.area to a file: URL that points to > the directory the org.eclipse.osgi jar is located. > > Of course, the easy way to avoid all of this is to always use Felix. ;-)
That would be very good I agree - except that SWT does not work well in other osgi frameworks - credit to Alex Blewitt for the info... https://bugs.eclipse.org/bugs/show_bug.cgi?id=201700 Which is my first interest in getting this working (so I can debug sigil using the sigil launcher) saves me doing nasty log debug statements if I can just walk through the code... > >> I've just committed the skeleton code I've been putting together for a >> sigil launcher in svn revision 801990 - it's trivial at this stage as >> I haven't had much time to look at this yet, also by the sounds of >> things I might be duplicating effort if I'm able to use the launcher >> you refer to? >> > > Well, the launching code I am referring to is based on the code from our > book: Ah yes, that one :) I was thinking you meant one on felix Regards, Dave > > > http://code.google.com/p/osgi-in-action/source/browse/trunk/launcher/src/launcher/Main.java > > However, to work with Equinox I created the attached modified version, which > I will try to merge back into the above example. > > -> richard > >
