Maven dependencies not resolved

GENERAL
1

I have been struggling with this issue for several days. I’m using the latest Eclipse, Java 17, and the Bndtools plugin. Bndtools downloads dependencies via Maven when I define the dependencies in the pom.xml in the workspace. The problem is that the projects are unable to fetch the dependencies defined in the pom.xml (i’ve confirmed that they exist in .m2/repositories locally) when used in a class. The project’s bnd.bnd looks like this:
buildpath:
org.mybatis:mybatis;version=3.5.11,

Bndtools gives me the error: Not found in… even though .m2/repositories is listed in the repositories it should search in.

Does anyone have an idea?

2

There has been this fix. BndPomRepository should support both bsn and gav like MavenBndRepository by chrisrueger · Pull Request #5964 · bndtools/bnd · GitHub which might be related.
Could you try with latest 7.1. SNAPSHOT (see)

3

Thanks. I’ll try it! What is the reccomended way of installing this snapshot in eclipse, replacing the version i got from the repository? The snapshot link i not a valid repository

4

It is the second link:
https://bndtools.jfrog.io/bndtools/update-snapshot

I have put it in Help / Install new Software

image
image1578×574 84.5 KB

1 Like
5

The snapshot do only have the .min alternative for workspace. I copied my previous build.bnd, but it didn’t work without error (caused: error when polling index (…m2\repository) and already closed mavenbndrepository.
Its maybe to unstable ?!

6

There are quite a lot of changes in 7.1.0 and SNAPSHOT is from current Master, so yes, there might be bugs.

Regarding the .min workspace.
Yes the other one was removed. In the changelog link above there is also a section if you still want to use the old one:

Feel free to report any findings in an issue.
We would need more detailed stack traces.

7

Do you see your dependencies in the Repository View? Additionally: How have your defined your dependencies in the pom for the BndPomRepository? As Dependencies or in the DependencyManagement section?

8

Yes, I see the Maven central repository, but nothing happens when I expand it (which may be correct for all i know).
What I do is this:
1: create a workspace with the predefined template (the one with default repositories predefined)

...
-plugin.6.Central: \
	aQute.bnd.repository.maven.provider.MavenBndRepository; \
		releaseUrl=https://repo.maven.apache.org/maven2/; \
		index=${.}/central.maven; \
		readOnly=true; \
		name="Maven Central"
...

2: Create a project and define f.ex this package in the project.

-buildpath: \
	org.mybatis:mybatis;version=3.5.10

3: I’ve also tried to define this in build.bnd without luck

-maven-dependencies: \
    org.mybatis:mybatis:3.5.10

As i understand it bndtools should populate the central.maven file with the packages I define in bnd.bnd with all its dependencies (GAV format). This does not happen. They do not even get downloaded into local (.m2/repositories). If i edit the file manually and resolve all dependencies myself, the libraries are downloaded and things work. But i would like to avoid doing that and let maven resolve all dependencies automatically. It look like something goes wrong in the repository fetching in build.bnd.

If I define a pom.xml in the workspace the files are downloaded in .m2/repositories, but i still cannot get the project bnd.bnd to resolve it and download into the project.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>your.group.id</groupId>
    <artifactId>your-artifact-id</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.11</version>
        </dependency>
        <!-- Other dependencies -->
    </dependencies>

    <repositories>
        <repository>
            <id>central</id>
            <url>https://repo.maven.apache.org/maven2</url>
        </repository>
    </repositories>

</project>

So i’m prettly clueless right now :slight_smile: I guess its something obvious i’m missing (as usual) but i can’t spot it.

9

Ah, I see what the misunderstanding is.

bnd does not populate the central.maven file for you. As a general explanation: In the build.bnd you can define plugins. They are quite generic and have a brought range of purposes (similar to Mojos for Maven). A bunch of them are Repository plugins. We support a brought range of them but the 2 Main ones that should be of use to you are aQute.bnd.repository.maven.provider.MavenBndRepository and aQute.bnd.repository.maven.pom.provider.BndPomRepository. With them you define the avilable pool of dependencies, the projects can use. Thus, you have to add org.mybatis:mybatis:3.5.11 to your central.maven file and then you can use it in your - buildpath. If it is a bundle already, you can reference it via its symbolic name or in the format you have. If it is no OSGi Bundle, you need the Version you already use.

You can put a POM file in your project as well, and reference it in your bnd.bnd with -pom: pom.xml but I’m not sure if it look in the dependency section for anything to add to the buildpath. It will definitely not look at the repository definition in the pom.

Please note, that the MavenBndRepository will only make available what is referenced in the index file and will not look for any dependencies. If you want to have that, you can use Bnd Pom Repository | bnd. Even though the POM Repo makes some things easier, as it looks at the dependency section as well, it is likely that it will download half the internet and everything will become a dependency hell. Manually curating your dependencies via the maven index file, is a bit more effort at the beginning, but it will give you less trouble in the long run.

10

Ok, thanks! I understand…so I was not that far off after all :slight_smile:
I see the problem with dependencies. I had one case recently where i had to include 20-30 dependencies to make it run in the osgi container - it was kind of cumbersome manually job.

Anyhow; thanks a lot for your help, and I hope my struggle is over (for now)

11

There is some help for that. If you add one dependency to the your index file, you will see the dependency in your repository view. There you tell the ide to add the runtime or compile dependencies for you. It will not solve everything, but it gives you a starting point you need to groom afterwards.

image
image1095×469 124 KB

1 Like
12

very nice!
I’didnt know that

13

I always found the configuration for the standard plugins too cumbersome to maintain and therefore developed my own. Maybe it suits your needs: Bnd Indexed Maven Repository | de.mnl.osgi

1 Like
14

@mnlipp The idea behind your repo seems nice and I will give it a shot as well. Ever thought about contributing it to bnd?

1 Like
15

This sounds great. I will test it too.

16

@mnlipp great. If you would like to give your plugin some more visibility inside bndtools, a first step could be to provide a workspace template fragment. This is a new - simple - mechanism in upcoming 7.1.0 to provide little template “snippets”

image
image1664×1218 168 KB

See here how to add one: Templates for Workspaces | bnd

I haven’t tried myself yet, but as I see it you just have to provide

  • a folder
  • in a / your github repo
  • with a .bnd file containing your plugin config
-plugin.1.IndexedMaven: \
    de.mnl.osgi.bnd.repository.maven.provider.IndexedMavenRepositoryProvider; \
        name=IndexedMaven; \
        location=cnf/indexed-maven; \
        releaseUrls="https://repo1.maven.org/maven2/"; \
        logIndexing=true
        
-pluginpath.IndexedMaved: \
    ${workspace}/cnf/cache/de.mnl.osgi.bnd.repository-6.2.0.jar;\
        url=https://github.com/mnlipp/de.mnl.osgi/raw/master/cnf/release/de.mnl.osgi.bnd.repository/de.mnl.osgi.bnd.repository-6.2.0.jar,\
    ${workspace}/cnf/cache/biz.aQute.repository-7.0.0.jar;\
        url=https://repo1.maven.org/maven2/biz/aQute/bnd/biz.aQute.repository/7.0.0/biz.aQute.repository-7.0.0.jar

Additionally this folder could also contain your cnf/indexed-maven and the subfolder de.mnl.osgi which includes an example of your group.properties file.

Once your repo is ready you / could just add a reference to this index workspace-templates/index.bnd at master · bndtools/workspace-templates · GitHub

Then this would be basically a “light” integration into bndtools and make it visible for every bndtools user as part of the New Bnd Workspace dialog (which also allows to update the current workspace).

17

The idea behind your repo seems nice and I will give it a shot as well. Ever thought about contributing it to bnd?

Nobody would be happy about this. I’m using bnd’s “internal APIs” as I succeeded in understanding them. This has never been easy because, let’s face it, bnd source code (at least the code related to repositories) is poorly documented (e.g. MavenRepository hasn’t a single comment!) . I once made an attempt to smuggle in what I consider good documentation with a PR but failed. (Else, at the time, I might have continued to document my understanding of the code.) (The really bad thing about this sparse documentation is that the style rubs off: my plugin’s documentation doesn’t meet my own standards, most likely because I never attempted to generate the javadoc and use it as a reference, as I usually do.)

Maybe due to the lack of documentation, I’ve never understood the class design in bnd’s repository packages and therefore the plugin is based on what you might call a “wrapper layer”. I’ve also found some problems with bnd’s attempt to provide it’s own parser for POMs and therefore use the Model class from the maven libraries (together with their parser).

Honestly, my code integrated into bnd would drive anybody trying to understand the different and duplicate approaches in bnd’s repository handling code crazy (without knowing about the history).

Also consider that the “Indexed Maven Repository plugin” is not in line with what I have understood to be “OSGi best practices”. It doesn’t provide a “carefully curated” repository. Rather, unless you specify some filters, you get all artifacts from a maven group and even automatic updates. You have to decide after the resolution (by comparing the new result with the previous one) if you go along with the upgrade of referenced libraries/bundles or you don’t. Of course, this is still slightly better than some non-OSGi “casual maven or gradle resolution” where referenced libraries are upgraded in your runtime without notice.

18

If you would like to give your plugin some more visibility inside bndtools, a first step
could be to provide a workspace template fragment.

Added PR as suggested. (Hey, I’m the first snippet contributor.)