How to add local JARs as build dependencies of a bundle

Hi
I followed the tutorials on bndtools but I could not understand how to add a JAR file as a build dependency to a bundle.

With PDE I could just create a lib folder in my module and add it to the MANIFEST as a build path.
Bndtool has the concept of repositories but I’m unable to make one locally.

Any help?

The easiest is to use a Maven Central repository since it is quite universal nowadays and keeps the build small. This is explained in the videos. Please remember that all repositories are defined in the cnf/build.bnd file.

If you want a local file based repository then you can add the following plugin in build.bnd:

 -plugin: \
    aQute.bnd.deployer.repository.LocalIndexedRepo;\
	  name                =MyRepo;\
	  local               ='${.}/myrepo'

You can then drop JARs on this entry in the Repository view. This will open a dialog for importing the JAR file.

1 Like

Thank you very much!
Where can I find documentation for that option and the ones regarding repositories in general?
I checked this but didn’t find this one in particular.

Furthermore, when I add the jar file it complains that it is not a bundle JAR. Do I need to wrap it into a bundle? Is that necessary?

Screenshot 2022-01-26 204524

And are there other methods to add the jar without a drag and drop, aka where is the folder where the jar files will be stored?

Moreover what is the best practice in naming convention for local repositories?

Well, JARs that are not bundles are just bad JARs … They are unusable in an OSGi environment and need wrapping.

If you need to wrap them, you can use these bad JARs by placing them in a directory in your project (e.g. jar). In the bnd file you can then add them to the -buildpath or -testpath in the project’s bnd.bnd file using version=file. If you set version=file, the bundle symbolic name part is the file path relative to the bnd.bnd file. For example:

  -buildpath: \
       org.osgi.framework, \
       jar/eproperties_deps-1.1.5.jar;version=file, \
       org.osgi.service.cm

OSGi is the loveliest environment you can imagine if you just follow the rules. However, it is a mean bitch when you want it to work with bad inputs. In my awfully long experience, the far majority of problems I see people having with OSGi (or for that matter generally in software) is because they tend to want it to digest stuff that is not up to snuff. Often driven by the idea that a shortcut will save time. It won’t in the long run.

Modularity is like security, it requires you to do everything right to get the payoff. But in the case of OSGi, that is a surprisingly high payoff.

Documentation for bnd instructions you can find on bnd.bndtools.org.