Develop Reference

Undertow application not starting up when running jar with dependencies

I am practicing with Kotlin and wanting to run a lightweight Rest application. I have experience with Undertow with Jersey, Jackson and Weld CDI in Java.
I wrote the minimum to startup the web container and it's running fine in IntelliJ.
Altough, when I try to run the jar-with-dependencies with java -jar app-with-dependencies.jar, I get errors.
Main class:
package nl.orhun.samplerestapp
import io.undertow.Handlers
import io.undertow.Undertow
import io.undertow.servlet.Servlets
import io.undertow.servlet.Servlets.servlet
import nl.orhun.samplerestapp.config.JerseyConfig
import org.glassfish.jersey.servlet.ServletContainer
import org.jboss.weld.environment.servlet.Listener
fun main() {
val servletBuilder = Servlets.deployment()
servletBuilder.setClassLoader(ClassLoader.getSystemClassLoader())
.setContextPath("/app")
.setDeploymentName("app.war")
.addListener(Servlets.listener(Listener::class.java))
.addServlets(
servlet("jerseyServlet", ServletContainer::class.java)
.setLoadOnStartup(1)
.addInitParam("javax.ws.rs.Application", JerseyConfig::class.java.name)
.addMapping("/rest/*")
)
val manager = Servlets.defaultContainer().addDeployment(servletBuilder)
manager.deploy()
val path = Handlers.path(Handlers.redirect("/app"))
.addPrefixPath("/app", manager.start())
val server = Undertow.builder()
.addHttpListener(8090, "localhost")
.setHandler(path)
.build()
server.start()
}
Error:
$ java -jar target/nl.orhun.samplerestapi-1.0-SNAPSHOT-jar-with-dependencies.jar
Mar 06, 2019 9:04:48 PM org.jboss.weld.environment.servlet.Listener contextInitialized
INFO: WELD-ENV-001007: Initialize Weld using ServletContextListener
Mar 06, 2019 9:04:48 PM org.jboss.weld.bootstrap.WeldStartup <clinit>
INFO: WELD-000900: 2.4.8 (Final)
Mar 06, 2019 9:04:48 PM org.jboss.weld.bootstrap.WeldStartup startContainer
INFO: WELD-000101: Transactional services not available. Injection of #Inject UserTransaction not available. Transactional observers will be invoked synchronously.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.glassfish.hk2.osgiresourcelocator.ServiceLoaderImpl because of underlying class loading error: Type org.osgi.framework.BundleListener not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.jboss.logging.JBossLogManagerLogger because of underlying class loading error: Type org.jboss.logmanager.Level not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.jboss.weld.injection.spi.helpers.ForwardingJpaInjectionServices because of underlying class loading error: Type javax.persistence.EntityManager not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from io.undertow.servlet.osgi.Activator because of underlying class loading error: Type org.osgi.framework.BundleActivator not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.jboss.weld.jsf.FacesUrlTransformer because of underlying class loading error: Type javax.faces.context.FacesContext not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.glassfish.jersey.internal.OsgiRegistry$OsgiServiceFinder because of underlying class loading error: Type org.osgi.framework.SynchronousBundleListener not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
INFO: WELD-000119: Not generating any bean definitions from org.glassfish.jersey.server.internal.scanning.PackageNamesScanner$1 because of underlying class loading error: Type org.osgi.framework.SynchronousBundleListener not found. If this is unexpected, enable DEBUG logging to see the full error.
Mar 06, 2019 9:04:49 PM org.jboss.weld.bootstrap.MissingDependenciesRegistry handleResourceLoadingException
<.... truncated...>
Exception in thread "main" java.lang.RuntimeException: org.jboss.weld.exceptions.DeploymentException: Malformed class name
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
at nl.orhun.samplerestapp.MainKt.main(Main.kt:26)
at nl.orhun.samplerestapp.MainKt.main(Main.kt)
Caused by: org.jboss.weld.exceptions.DeploymentException: Malformed class name
at org.jboss.weld.executor.AbstractExecutorServices.checkForExceptions(AbstractExecutorServices.java:66)
at org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:43)
at org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:51)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer.addClasses(ConcurrentBeanDeployer.java:58)
at org.jboss.weld.bootstrap.BeanDeployment.createClasses(BeanDeployment.java:224)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:398)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:191)
at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:125)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:216)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:185)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:250)
... 2 more
Caused by: java.lang.InternalError: Malformed class name
at java.lang.Class.getSimpleBinaryName(Unknown Source)
at java.lang.Class.isMemberClass(Unknown Source)
at org.jboss.weld.util.reflection.Reflections.getNesting(Reflections.java:138)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedConstructor.initParameters(BackedAnnotatedConstructor.java:50)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedConstructor.initParameters(BackedAnnotatedConstructor.java:28)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedCallable.<init>(BackedAnnotatedCallable.java:34)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedConstructor.<init>(BackedAnnotatedConstructor.java:38)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedConstructor.of(BackedAnnotatedConstructor.java:32)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:168)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.computeValue(BackedAnnotatedType.java:161)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:58)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:157)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:161)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedConstructors.<init>(BackedAnnotatedType.java:161)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:62)
at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:46)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:80)
at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.apply(ClassTransformer.java:77)
at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache$1.apply(ReentrantMapBackedComputingCache.java:55)
at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache$1.apply(ReentrantMapBackedComputingCache.java:51)
at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getValue(ReentrantMapBackedComputingCache.java:64)
at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getCastValue(ReentrantMapBackedComputingCache.java:80)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:192)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:83)
at org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:61)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:58)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -6
at java.lang.String.substring(Unknown Source)
... 35 more
Build segment of the pom:
<build>
<plugins>
<plugin>
<artifactId>kotlin-maven-plugin</artifactId>
<groupId>org.jetbrains.kotlin</groupId>
<version>${kotlin.version}</version>
<executions>
<execution>
<id>compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<sourceDirs>
<sourceDir>${project.basedir}/src/main/kotlin</sourceDir>
<sourceDir>${project.basedir}/src/main/java</sourceDir>
</sourceDirs>
</configuration>
</execution>
<execution>
<id>test-compile</id>
<goals>
<goal>test-compile</goal>
</goals>
<configuration>
<sourceDirs>
<sourceDir>${project.basedir}/src/test/kotlin</sourceDir>
<sourceDir>${project.basedir}/src/test/java</sourceDir>
</sourceDirs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>nl.orhun.samplerestapp.MainKt</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I am thinking that this has something to do with how I create the jar file but I'm not sure.
Why is my application not starting up when I run the jar file?

I'm not using Undertow, but I use Weld SE in a servlet setup running on Jetty and ran into the same issue as you, it seems like. I had some luck with excluding kotlin-packages from the bean discovery scan in my beans.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all"
version="1.1">
<scan>
...
<exclude name="kotlin.**" />
<exclude name="kotlinx.**" />
</scan>
</beans>
I tried debugging the issue, and for me, the java.lang.InternalError: Malformed class name originated from the Java Class.getSimpleBinaryName called on some lambda in the body of kotlin.coroutines.CoroutineContext.plus, named kotlin.coroutines.CoroutineContext$plus$1 that apparently has the enclosing class kotlin.coroutines.CoroutineContext$DefaultImpls which is 6 characters longer than the lambda class name, causing an IndexOutOfBoundsException when trying to substring the lambda name with the length of the enclosing class name to get the simple name of the lambda. This may be seen as a bug in the way Kotlin names/types lambdas. A least with respect to reflection.
I also tried replicating the problem by creating this interface:
interface Foo {
fun fooBar(operation: (Foo) -> Foo): Foo
fun plus(foo: Foo): Foo = fooBar { f -> f.plus(f) }
}
And it causes the same problem (with or without operator before fun). Making Foo a class, and implementing fooBar, makes the problem go away though. Don't know why.
Using for instance let in the body of Foo.plus didn't cause any problems. Probably because let is inlined. So if you can stay away from using un-inlined lambdas in interface function bodies, you might be okay. And you can always put the interface causing problems in a package of its own and exclude this from being scanned, if you are not going to inject it. Hopefully this problem is not widespread.
Hope this helped, despite not being an Undertow-specific answer!
EDIT: You can add the #JvmDefault (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/-jvm-default/index.html) annotation to an implemented function in an interface to create default method (Java 8 feature) compatible bytecode, and hence eliminate the problem described above. Note that you then have to specify the -Xjvm-default=enable or -Xjvm-default=compatibility compiler argument. More light is shed over #JvmDefault in this article: https://realjenius.com/2018/06/29/jvm-default/.

Share Classloader between multiple in Jetty Maven Plugin

I'm try to configure maven jetty plugin to start my war application, but it has some complications like as follow descriptions:
1º - It has dependencies with a ejb jar;
2º - It has dependencies with war (tag jstl:import context="nscl");
3º - The classloader between wars must be shareded.
So, I need some help to resolve the third problem. Looks my jetty plugin configuration in pom.xml:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.4.1.v20170120</version>
<configuration>
<useProvidedScope>true</useProvidedScope>
<useTestScope>true</useTestScope>
<webApp>
<contextPath>/nscl/cntr</contextPath>
</webApp>
<contextHandlers>
<contextHandler implementation="org.eclipse.jetty.maven.plugin.JettyWebAppContext">
<war>${contexto.war.path}</war>
<contextPath>/nscl</contextPath>
</contextHandler>
</contextHandlers>
<systemProperties>
<systemProperty>
<name>spring.profiles.active</name>
<value>test</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>
The problem is, when jetty is starting the second war (context-path = nscl), I receive problems saying the classes used to start first war not exist to second, a sample is classes of spring framework.
Thanks !!!!

You are hitting Standard Servlet Spec behavior.
Your WebApp's cannot share the same ClassLoader.
That is a fundamental part of being a Servlet Spec WebApp, the ClassLoader isolation.
Attempting to force it will just create mysterious problems with the ClassLoader hierarchy (InvalidClassChange errors, memory leaks, GC failures, etc)
Perhaps you can detail why you think you need this.
As there's likely already a standard way to accomplish it using the features of the Servlet spec (and not fighting it).

Can't get rid of Split package, multiple jars provide the same package

I have main project (projectA), which has a library depencency (projectB), both has package.subpackage in them. I would like to inline the library in the main project. Main project configuration is quite simple (in addition the the depencency listed with 'compile' scope:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.4.0</version>
<extensions>true</extensions>
<configuration>
<instructions combine.inherited="append">
...
<Export-Package>package.*;version=${packet.version};-split-package:=merge-first</Export-Package>
<Bundle-SymbolicName>${project.artifactId};singleton=true</Bundle-SymbolicName>
</instructions>
</configuration>
</plugin>
Yet it yields following warning
--- maven-bundle-plugin:2.4.0:bundle (default-bundle) # projectA ---
Bundle project:projectA:bundle:version : Split package, multiple jars provide the same package:project/subproject
Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning
Package found in [Jar:., Jar:subproject]
Class path [Jar:., Jar:subproject]
I have split-package directive yet the warning persists.
What I would love it a way to simply inline everything from the explicitly listed artifact and nothing more (even if there are more dependencies stated), without any transitive dependencies. Preferably without any warnings about split package.

I think that you need the maven shade plug-in

Jersey exception only thrown when depencencies assembled into a single jar

I'm writing a server that embeds Jetty w/ Jersey. When I execute from Eclipse, everything is great. However, if I assemble my server and all dependencies into a single jar using Maven's assembly:single goal, I get an exception:
Sep 26, 2012 5:35:59 PM com.sun.jersey.spi.container.ContainerResponse write
SEVERE: A message body writer for Java class com.acme.server.webservice.
exception.WebServiceFailure, and Java type class com.acme.server.webserv
ice.exception.WebServiceFailure, and MIME media type application/json was not fo
und
Sep 26, 2012 5:35:59 PM com.sun.jersey.spi.container.ContainerResponse write
SEVERE: The registered message body writers compatible with the MIME media type
are:
*/* ->
com.sun.jersey.server.impl.template.ViewableMessageBodyWriter
17:35:59.372 [qtp184245201-22 - /] ERROR o.a.h.ReflectorServletProcessor - onReq
uest()
javax.ws.rs.WebApplicationException: com.sun.jersey.api.MessageException: A mess
age body writer for Java class com.acme.server.webservice.exception.WebS
erviceFailure, and Java type class com.acme.server.webservice.exception.
WebServiceFailure, and MIME media type application/json was not found
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerRespons
e.java:285) ~[vma-server-0.0.1-SNAPSHOT-jar-with-dependencies.jar:na]
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequ
est(WebApplicationImpl.java:1457) ~[server-0.0.1-SNAPSHOT-jar-with-dependenc
ies.jar:na]
...
The full trace is here, if it's useful:
https://gist.github.com/3790817
Maven throws no errors while creating the jar-with-dependencies.
I'm a novice with Maven and deployment of Java, and I'm really not sure how to proceed with debugging.
Also, while I need to solve this issue I'd also appreciate any suggested work-arounds as I need to produce an executable demo of my server ASAP that a Pointy-Haired Boss (tm) can execute without Eclipse.
Solution:
Based on Pavel's answer, I dropped the maven-assemly-plugin in favor of maven-shade-plugin. Here's the shade configuration that worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<!-- use transformer to handle merge of META-INF/services - see http://java.net/jira/browse/JERSEY-440?focusedCommentId=14822&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_14822 -->
<transformer
implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
</transformers>
<filters>
<!-- filter to address "Invalid signature file" issue - see http://stackoverflow.com/a/6743609/589215-->
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>

You are not merging Jersey jars correctly.
Jersey 1.x uses META-INF/services mechanism to discover its components and assembly:single probably just copies everything into single jar, overriding already present files BUT META-INF/services file(s) needs to be CONCATENATED.
Try using jersey-bundle (com.sun.jersey:jersey-bundle:1.14) or fix your assembly settings (or find another plugin to do it better).

Could you post your pom ?
Do you mark some dependencies as provided ?
It's something quite different to build a standalone app and a webapp, as some jars a supposed to be provided by the web container (tomcat or other).
As your container is "embedded" in your app (and not your app in the container) then maybe you don't manage correctly these dependencies.

Deploying a Maven Built OSGi Package in ServiceMix: "Unresolved constraint in bundle ..."

I can build my projects "samba.interfaces" and "samba.message" without problems. But when I try to start "samba.message" bundle in ServiceMix (requires the "samba.interfaces" bundle that contains the package de.samba.common), I get the following error:
Error executing command: Unresolved constraint in bundle message [195]: module;
(&(bundle-symbolic-name=de.samba.common)(bundle-version>=0.0.1))
So, what is the symbolic name used for? Does it have to be the same as the main package? This is the part of the POM that specifies the message bundle:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.2.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>de.samba.message.Activator</Bundle-Activator>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Bundle-Name>SAMBA Message</Bundle-Name>
<Bundle-Version>1.0.0</Bundle-Version>
<Import-Package>
javax.jws,
javax.wsdl,
javax.xml.bind,
javax.xml.bind.annotation,
javax.xml.namespace,
javax.xml.ws,
META-INF.cxf,
META-INF.cxf.osgi,
org.apache.cxf.endpoint,
org.apache.cxf.bus,
org.apache.cxf.bus.spring,
org.apache.cxf.bus.resource,
org.apache.cxf.configuration.spring,
org.apache.cxf.resource,
org.apache.cxf.service.model,
org.apache.cxf.jaxws,
org.apache.cxf.transport.http_osgi,
org.springframework.beans.factory.config,
org.springframework.beans.factory.xml,
org.springframework.core.io,
org.springframework.beans.factory,
org.springframework.context.support,
org.springframework.beans,
org.springframework.context,
org.osgi.framework,
org.apache.log4j,
de.samba.common.auditingcontrol.*,
de.samba.common.collect.*,
de.samba.common.message.*,
de.samba.common.repository.*,
de.samba.common.security.*,
de.samba.common,
*
</Import-Package>
<Export-Package>de.samba.message.*</Export-Package>
<Private-Package>
</Private-Package>
<!--
<DynamicImport-Package>*</DynamicImport-Package>
-->
</instructions>
Any ideas what might cause this error?

I do not have much idea of OSGI, but have the following observations.
The documentation specifies how <Bundle-SymbolicName> is computed. In their Real-World Example, they do not seem to have the projectId.
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>

Okay, I found the problem myself. Error executing command: Unresolved constraint in bundle message [195]: module; (&(bundle-symbolic-name=de.samba.common)(bundle-version>=0.0.1)) was completely unexpected, and it came from having a MANIFEST.MF file inside src/main/resources/META-INF that usually describes the bundle information if you're doing plugin/OSGi development. Seems that the Maven BND Plugin includes that file and ONLY generates new information if it isn't there.
So the problem was solved after removing src/main/resources/META-INF/MANIFEST.MF so the plugin could generate the proper one.