Re: [equinox-dev] CVS module questions

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

equinox-dev-admin@xxxxxxxxxxx wrote on 03/10/2005
12:25:43 AM:

> Jeff McAffer wrote:
> > thoughts/questions:
> > 
> > - in M6 we are improving the ability to use the Eclipse OSGi
standalone. 
> >  This includes packaging it as one jar and including a main()
that just 
> > runs OSGi and a console.  I suspect this is not quite what
you want but 
> > is worth stating anyway :-)
> 
> As a straight-up OSGi user, I'd like to see better documentation on
the 
> eclipse osgi layer, particularly the stuff in osgi that is left up
to 
> the implementation, such as how things are stored, how bundles are
> unpacked, etc.

Sounds reasonable.  Can you supply more info
on why you want/need this information?  It is implementation detail.
 Even if we document it, it will not be API so you should not be relying
on it or using it.  If we understand your mindset better we can better
target the doc.

> It would be great if you had a distribution with
just the runtime. 
> Right now I have the jars and ancillary files pulled out of the plugin.
>   It works but its own distribution would be a big help.  Sounds
like 
> what you mention for M6.

Yup.  There are no plans to make a separate distribution
but you will be able to get the RCP drop and then just use the org.eclipse.osgi_3.1.0.jar.
 It will contain everything you need (excluding startup.jar)

> Further, I'd like to see a nice API for setting
up the initial 
> environment.  I'd rather configure things in Java code than the
> properties files.  Of course, this is might be there but it means
I have 
> to figure it out, as opposed to documentation for exactly this.

You can configure things in code.  The property
files are just a convenience for those who don't want to wrapper or write
code.  In general we are careful not to overwrite properties which
are already set.  So you can simply write some code that sets up the
required properties and away you go.  See
        http://help.eclipse.org/help30/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html

for details on the applicable system properties.  Note
that a few have been added since 3.0.  We are in the process of documenting.

> > - how do you automatically install bundles
on other OSGi implementations?
> 
> Properties.  You set properties for the root of the installed
bundles 
> dir and props for the path/to/bundles to load and props for startlevels,
> etc.  This is similar to how Eclipse currently does it.
> 
> > - I'm assuming that since you run your stuff on other OSGi 
> > implementations that you do the work of your application/system
in the 
> > start() method(s) of some bundles.  If so, why do you want
to use 
> > startup.jar?
> 
> I was evaluating startup.jar just to see what it could offer.  We
ship 
> embedded web apps, so I have been curious to see what we could learn
or 
> leverage from the next level up in the eclipse design.

The main thing that startup.jar gives you are
- classloader isolation.  The launcher creates
a new classloader parented by null for loading the framework itself.  This
effectively isolates OSGi/Eclipse from the Java app classpath.
- it searches for the OSGi framework implementation
to use.

Jeff