Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Handling non-osgi/non-p2 available dependencies?

In some cases I need to export. I know how to use felix for adding
bundle headers for a native maven project. But what do you mean by
creating a separate OSGi wrapping? Assume that at build time I
download and copy the following dependency from nexus:


how do I create an OSGI wrapper for that dependency? Or do I need to
create a new plugin project (plugin form existing jar) which uses the
downloaded dependency? I have also tried this but it involves to many
manual steps and is also hard to maintain when the version is updated.

On Tue, Feb 28, 2012 at 10:16 AM, Oberlies, Tobias
<tobias.oberlies@xxxxxxx> wrote:
> See inline
>> -----Original Message-----
>> From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-
>> bounces@xxxxxxxxxxx] On Behalf Of motes motes
>> Sent: Montag, 27. Februar 2012 13:59
>> To: Tycho user list
>> Subject: [tycho-user] Handling non-osgi/non-p2 available dependencies?
>> This has been up many times before - how to handle non-osgi/non-p2
>> dependencies in an eclipse pde project when building with tycho.
>> We have previously used the tycho-extra plugin to build a p2 site with
>> the required dependencies (only works if they already have meaningful
>> bundle-headers in the manifest file) in combination with felix (to add
>> bundle headers for non-osgi projects).
>> Now we simply use the maven-dependency-plugin to copy the necessary
>> dependencies from nexus at build time to the bundle project root and
>> add it to its classpath. The advantage is that it can be done in the
>> same reactor and is private for the project.
> The key term here is "private": As long as you don't export anything from the dependencies you are embedding, this approach is okay. However this basically forces you to only use the dependencies from one single bundle.
> However things change as soon as you need to export something from the included dependencies. Then you basically create an OSGi wrapper in your own bundle, and that can mean OSGi hell for your users: If they combine your bundle with something else using the same library, your bundle is likely to collide with other wrappers for the library.
> So, if you need to export, build a separate OSGi wrapper, e.g. with Felix.
> Regards
> Tobias
>> Are there a better way to do this/how do you guys handle this problem?
>> _______________________________________________
>> tycho-user mailing list
>> tycho-user@xxxxxxxxxxx
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx

Back to the top