On 8/7/09 10:11, David Savage wrote:
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 see, well, at least the Eclipse team appear to be working on it...it
has only been a few years...
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
The only in Felix has to be modified to use the META-INF/services
approach and to handle auto-deploy of bundles slightly differently. The
current assumption is that the Felix launcher will only be used with the
Felix framework, but I could make it more generic...maybe I will create
an issue...
-> richard
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
