[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] CVS module questions


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