[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Bundle lookup

Hi Peter,

the problem with syslinks is that the application has to run on both linux- and windows based systems.

This Hansa project is very interesting and now i know how this platform:/ url works.

Thanks, I think this will help me a lot!


Peter Neubauer wrote:
Hi Michael,
This is a compile time solution, of course. If you want to link URL:s to
changing actual bundle locations, you could do it on linux of curse via
Symlinks in the file system, but a more generic way would be to install
a custom protocol handler. Eclipse does this with the platform:/
protocol, another system using this, including links from one URL to
another is here:

There is a Transit bundle registering that kind of system into OSGi, so
you can use it to update your bundles at runtime

If nothing else, the code should show how to register custom URL


-----Original Message-----
From: Michael Mangeng [mailto:mm@xxxxxx] Sent: Sunday, January 22, 2006 10:19 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bundle lookup

Hello Peter,

thanks for your input!

Hmm - I'm searching for a automatic bundle lookup which works at runtime but I'll think wether the solution you suggested is enought for my needs or not. Maybe it is enought and i don't really need what i'm looking for :-)


Peter Neubauer wrote:

Hi Michael,
On Sunday 22 January 2006 21:29, Michael Mangeng wrote:

The problem is that I dont know which approach I have to

take when I

want to install "the highest version" of e.g. bundle1 so the upper sample-xml should install bundle1-1.2.0.jar (if this is the highest version available).

For our development we use ivy

(http://www.jayasoft.org/ivy), and have

written a little ant task that produces a config.ini fole

that Equinox

reads for deploying bundles. That way, we specify start

levels as Ivy

configurations and get dependency and of course version

handling for

free. The scenario you discribe is very common for us, a

usual Ivy.xml

file for a product assembly (that is, a product consisting

of several

bundles that are compiled using a previous stage in the

process) would look something like:

<?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet type="text/xsl"
<ivy-module version="1.0">
<info organisation="scancoin" module="test.assembly"


<repository name="scancoin" url="https://test"/>
<conf name="default"/>
<!--these are the runlevels, picked up by an ant task

and inserted

into the config.ini bundles statement-->
<conf name="1" visibility="private"/>
<conf name="2" visibility="private"/>
<conf name="3" visibility="private"/>
<conf name="4" visibility="private"/>
<conf name="5" visibility="private"/>
<conf name="6" visibility="private"/>
<conf name="localdir" visibility="private"/>
<artifact name="test.assembly" type="zip" conf="default"/>
<!-- core bundles -->
<!-- knopflerfish bundles -->
<dependency org="knopflerfish" name="cm"


<artifact name="cm_all" type="jar"/>
<dependency org="knopflerfish" name="console"


<artifact name="console_all" type="jar"/>
<dependency org="knopflerfish" name="log"


<artifact name="log_all" type="jar"/>
<!-- core bundles -->
<dependency org="scancoin" name="com.scancoin.core.module1" transitive="false" rev="latest.integration" conf="3->*"/>
<dependency org="scancoin" name="com.scancoin.core.module2" transitive="false" rev="latest.integration" conf="4->*"/>
<dependency org="scancoin" name="com.scancoin.core.module3" transitive="false" rev="latest.integration" conf="2->*"/>

<!-- OSGi container -->
<dependency org="eclipse" name="org.eclipse.osgi" rev="latest.integration" conf="localdir->*"/>
<dependency org="eclipse" name="org.eclipse.osgi.services" rev="latest.integration" conf="1->*"/>

Ivy will then copy the dependencies without the version into ${basedir}/lib/3/com.scancoin.core.module1.jar etc. and the

ant task

builds a config.ini from it that looks something like

osgi.bundles=lib/3/com.scancoin.core.module1@3:start etc.

This works great. If it helps and you want more info, maybe

I can help

you further.

equinox-dev mailing list

_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev