Bundle can't be found when custom BSN used about bnd HOT 6 CLOSED

What is the pom in this case? The workspace is a repository so it will look for the file names of the bnd files. I think we discussed this a long time ago, if you want to deviate from this model, we need to keep a current index of all workspace bundles actual names. Having to build this in the offline build is expensive for large workspaces.

from bnd.

This pom is as follows:

<groupId>org.example</groupId>
<artifactId>b1</artifactId>

The problem is that M2Eclipse forces the project to have the name $[artifactId}, i.e. just b1 in this case. Bnd works fine if the project name includes the groupId but this doesn't seem to be allowed by M2Eclipse.

Is there anything we can add to the runbundles to help it find the bundle? E.g.:

-runbundles: org.example.b1;project=b1

from bnd.

Yuck, this sounds like a road to hell :-( All these things can be so easily wrong in so many places.

But why do they want to use bndtools if they also use M2Eclipse? I have no problem being compatible with mvn the command line but M2Eclipse is a bit too close to bndtools? Why do you need both?

from bnd.

Felix is using the artifact id as the bsn, is that not the solution?

from bnd.

Using Bndtools with M2Eclipse is my current plan for supporting Maven users. M2Eclipse gives the build-time dependencies, Bndtools gives us on-the-fly builds, the launcher, the nice bundle editor etc.

Perhaps another solution is to cut out M2Eclipse and support the Maven build dependencies directly in Bndtools.

from bnd.

Felix is using the artifact id as the bsn, is that not the solution?

That would work for the launcher but I find it surprising that they don't qualify the BSN with the groupId.

Anyway I don't think it will be practical to release Maven support for Bndtools in time for EclipseCon. It's close but there are too many little things like this that still need to be worked out.

from bnd.