How to embed a maven dependency with bnd-maven-plugin - osgi

I am moving from maven-bundle-plugin which provided the "convenient" configuration using Embed-Dependency, but it appears i need to specify my Embed Dependency "manually" in bnd format when using the bnd-maven-plugin. I added the same bundle headers from my old package, but it doesn't seem to be including the actual dependency's jar file. Does someone have a quick/concise how-to do this?

bnd has an instruction -includeresource defined here https://bnd.bndtools.org/instructions/includeresource.html:
Here's an example:
-includeresource: lib/somelib.jar=somelib-[\w.]*.jar;lib:=true
This should have visibility into all the dependencies in the classpath used to build the artifact and matches on the file name of the associated files.
[Update with BJ's comment]
The lib:=true will automatically add the jar to the bundle's Bundle-ClassPath header in a merge safe way (i.e. by making sure it plays nice with existing content or non-existent value).

Related

How to correctly import a Maven dependency that I altered and re-built into an existing project?

I have a Maven dependency, pulsar-log4j2-appender, which I forked and changed the source code because it was throwing exceptions in my project.
After changing the source code, I ran the maven package command to build the jar and imported it into my project (in Intellij: Project Structure | Modules | Dependencies | Add JARs or directories...).
However, when I run the application, it seems like it's not able to find that dependency because the Pulsar appender which I declared in my log4j2.xml file isn't being configured.
Am I importing the JAR properly? I'm wondering if the JAR needs to be within the org.apache.pulsar namespace to be imported properly.
For example,
This is what the dependency looks like unaltered:
And this is what it looks like when I modify and build it myself:
If you modify the code from an open source project you should change both the groupId and the artifact id. If you do not you will have problems and future developers will say your name in ways you do not want to hear.
Changing these are necessary so that Maven knows to use your version instead of the publicly available version. Also, when people look at your project and see the groupId and artifactId from the "real" project they will naturally assume that is what is being used (which is why they will curse you if that is not the case). In addition, you will have to do something convoluted to get Maven to use your dependency reliably.
The practice I have followed is the prepend "com.mycorp", where mycorp is my employer's name, to the groupId and add mycorp into the artifactId. The only downside to this is that you must ensure that the "real" artifact's coordinates are not referenced as a dependency or as a transitive dependency or else you will have duplicate classes on the class path.
Finally, your best bet is to create a pull request for Apache Pulsar with your fix so that other people experiencing the same problem you are get the benefit of it.

OpenDaylight Nitrogen: where to specify repository for features?

Where do I specify repository paths in OpenDaylight Nitrogen (on Karaf 4.0)? I am building a Java application on this platform. I noticed that features.xml is generated from the POM. I need to load some features from my local Maven .m2/repository that are generated from another project. I see a features/features-X directory with a pom.xml where I can add the feature dependency, but where do I specify the repository in which to look for the feature?
This is probably more of a Maven question than an OpenDaylight question....
This is somewhat OpenDaylight-specific (although obviously the behaviour can be replicated using Maven in other contexts). As you’ve discovered, Karaf feature descriptors are now generated automatically, based on the POM dependencies. For this to work, the following requirements must be met:
the feature-generating module must have org.opendaylight.odlparent:single-feature-parent as its parent (transitively if necessary);
the POM must specify feature as its packaging type;
feature dependencies should be declared as build dependencies in the POM, using the default scope, with type set to xml and classifier set to features (plural).
If necessary, feature snippets can be given as src/main/feature/feature.xml (singular) in the corresponding module; these will be merged with the generated feature.xml (singular again). The result is installed as a features.xml (plural) file in the target repository.
It’s worth noting that feature descriptors generated in this fashion use each feature they depend upon as their own repositories; if you need a multi-feature repository instead, you should use a manually-generated feature descriptor.
This is briefly documented in the ODL Parent developer guide.
Just put it in as a dependency in features/features-X/pom.xml the plugin looks at the maven path and automatically generates the repository. ( Answering my own question so it could be of use to others. )

Creating uber jar with maven

My project inherits it's compile dependencies from parent and I have no control over it - can't change them to provided. Additionally, I have added another dependency 'a:b:1.0.0' to my project's pom. I want to include only 'a:b:1.0.0' with it's own dependencies (recursively ) to my uber jar.
Seems like neither assembly nor shade plugin doesn't support such case.
How this could be done ?
Thanks
Shading recursively has some significant disadvantages. Especially, the problem of duplicate files from multiple dependencies being overwritten with only a single version of the file. This can cause some pretty annoying problems to troubleshoot at runtime. You'd be better off using something like spring boot to build a standalone jar where instead of shading files into a single hierarchy, will embed dependent libraries into itself as a subdirectory and include on the classpath for you.
http://docs.spring.io/spring-boot/docs/current/maven-plugin/repackage-mojo.html

how can I find the artifactId and version information for '"libopencv_java.so" and "libnative_camera_r2.2.2.so" in pom.xml in Maven?

I've searched for hours but no artifactId and version information for "libopencv_java.so" and "libnative_camera_r2.2.2.so".. I know how to add dependency into pom.xml to be included in lib/armeabi in .apk, but I just cannot find the correct information.. The pox.xml keeps complaining
"Missing artifact org.opencv:libnative_camera_r2.2.2:so:2.2.2
Missing artifact org.opencv:libopencv_java:so:1.0"
Thank you so much~!!
These are native non-Java libraries. They aren't normally handled by Maven. If you would like to use static objects in your module, I suggest you have something like ${basedir}/lib and place your static libraries in there. Add the directory as a <resource/> as well and have it included in you jar. I think it should be possible to load the .so from within the jar. This is one option.
Another option would be, (if you really, really must re-use the .so-s across modules), to extract them to a separate module and have your module depend on that one.
Either way, you'll need to do quite a bit of magic, which isn't covered by Maven by default.

Let maven generate the Required-Bundles Header?

I want to let maven to create the header field Require-Bundle depending on my dependencies specified in the pom.xml.
I looked into the maven-jar-plugin but it does only support generation of the ClassPath header.
Does anyone know a maven plugin that can automatically generate the RequireBundle entry in the manifest out of my pom dependencies of scope provided?
Best regards
You should use the maven-bundle-plugin.
ADDENDUM:
More precisely, maven-bundle-plugin would only assist you when defining the dependencies of your bundle. It would not automatically construct a set of required bundles. This is because requiring bundles is not the recommended OSGi practice: you should depend on exported packages. For this reason, maven-bundle-plugin automatically fills the Import-Package, but would not do the same for Require-Bundle (either one or the another, anyway). Hence if you choose to take this road, you'll have to specify bundles manually anyway.
This does not count as a solution, but I thought it worth of discussion.

Resources