In my project, there is Karaf feature XML file contains all OSGi bundles. Now, this is used as dependency in other maven project's pom.xml file.
<dependency>
<groupId>a.b.c</groupId>
<artifactId>dummyfeature</artifactId>
<type>xml</type>
<classifier>features</classifier>
<version>1.0.0</version>
</dependency>
Now, following code is being used to install above feature.
KarafDistributionOption.features(
maven()
.groupId("a.b.c")
.artifactId("dummyfeature")
.version("1.0.0")
.type("xml")
.classifier("features"), "dummyfeature")
Is there a way to exclude a particular OSGi bundle from above feature programtically?
https://issues.apache.org/jira/browse/KARAF-5376 provides a way to alter the features read from XML file. You can:
blacklist some bundles
blacklist some features
override some bundles (like changing version or even group/artifact IDs)
override entire features
See this comment for overview of the mechanism. There's no documentation fragment yet (I didn't have time to do it). But for your particular case, you should add etc/org.apache.karaf.features.xml file with this content:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Configuration generated by Karaf Assembly Builder
-->
<featuresProcessing xmlns="http://karaf.apache.org/xmlns/features-processing/v1.0.0">
<blacklistedBundles>
<!-- there are several patterns you can use here -->
<bundle>mvn:groupId/artifactId</bundle>
<bundle>mvn:groupId/artifactId/1.0</bundle>
<bundle>mvn:groupId/artifactId/[1,2)</bundle>
</blacklistedBundles>
</featuresProcessing>
Related
I was understanding something in spring boot and to being with, used a very simple snippet, like adding this in pom.xml
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.1.RELEASE</version>
</parent>
As I understand <parent> in this context means that in my pom.xml, there we have a parent pom.xml (saw the pom.xml file for spring-boot-starter-parent) which will have list of dependencies.
The important thing is that it is only pom packaging, and NOT a real jar / binary (please correct if I am wrong)
I saw the following in mvn repository:
<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.1.RELEASE</version>
<type>pom</type>
</dependency>
My doubt is:
How can we include it as an dependency , it is just a pom packaging (and not a real jar / war), which acts as central place which holds common dependencies? Is it allowed? I tried adding in my project, but saw errors in STS IDE.
How does this get downloaded? Can we see the contents of this "parent"
First off, you've probably missed the meaning of parent pom in this case.
Spring boot of any specific version (2.2.1 in this case) comes with a bunch of possible integrations with many technologies / libraries. So it provides "default" versions of the libraries to work with because its very hard to check that it compatible with all possible versions of all libraries. You can of course provide your own version but then you should test a compatibility as an application maintainer.
So If you'll checkout the source code of spring-boot-starter-parent pom, you'll see that it provides some plugins and plugin management and more importantly inherits from another pom called spring-boot-dependencies
Note it doesn't add any dependencies to your project. It only defines a dependencyManagement section. This means that once you'll use the dependency in your project (that inherits) from this pom, you don't have to specify a version, only group id and artifact id.
Again, that's because spring boot offers by default very specific versions of thirdparties - the version that it was verified that it's compatible with...
Now as for the second part of the question - indeed it doesn't make sense to include dependency with packaging pom like you've posted, could you please provide a link where exactly you've seen this?
Sometimes when people adopt spring boot in their projects they already have have some parent, so they can't use the inheritance, in this case they can use a very special maven scope "import" and use the dependency on pom treating it as BOM (bill of materials) - frankly a pretty advanced stuff in maven. But spring boot uses this feature for these cases.
The dependency inclusion looks like this:
<dependencies>
...
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.2.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
Note, the `import line. From maven's site: This is meant to allow dependency management information such as versions and excludes be retrieved from a remote POM file.
Here is a tutorial about this topic
#CuriousMind, including the spring-boot-starter-parent as a dependency is like trying to instantiate an interface or Abstract Class in Java. As you noticed, its packaging is pom, meaning it is just a maven artifact to help configure your maven project. Jar and War will contain some java binaries. I think the MVN repository code automatically generate all sample as dependencies..
I am trying to convert my project into an OSGI application. I have few doubts. Suppose ModuleA in my application is dependent on external jars jarA and jarB. Now to make ModeuleA run, I am embedding both the jars using embed-dependency property of maven-bundle-plugin.
Now suppose I have another module ModuleB which is also dependent on jarA. So this module also embeds the jarA. My project ends up having jarA being embedded 2 times which will unnecessarily bloat the size of project.
Is there any way to tell OSGI to load jarA only once and provide it to both the modules.
If converting these jars to OSGI bundles is the only solution, I have few more questions:
What is the easiest way to convert jar to a bundle. BND tool looks like a good solution but I am not able to find proper documentation about it.
jarA will also have some dependent jars. So do I need to convert all the dependent jars to bundles also. My project has more than 100 jars. How can I automate this process.
Thanks in advance :)
There are actually to solutions to this, both a little bit different from what you are doing right now:
Build one "third party dependencies" bundle, which will embed all of the non OSGi dependencies your project has.
Convert every non OSGi dependency to a OSGi bundle.
Option 1 is easier to handle so I think most projects do this. I, personally, prefer option 2. We have a Maven "pom.xml" template that we use to convert those dependencies.
The "pom.xml" looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<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>
<properties>
<library.groupId></library.groupId>
<library.artifactId></library.artifactId>
<library.version></library.version>
</properties>
<artifactId></artifactId>
<packaging>bundle</packaging>
<name></name>
<description>${library.groupId}:${library.artifactId}:${library.version}</description>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Import-Package>*;resolution:=optional</Import-Package>
<Export-Package>*</Export-Package>
<Embed-Dependency>*;scope=compile|runtime;inline=true</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>${library.groupId}</groupId>
<artifactId>${library.artifactId}</artifactId>
<version>${library.version}</version>
</dependency>
</dependencies>
</project>
This does:
Add the non OSGi library as dependency
Tell maven-bundle-plugin to embed this dependency (transitive)
Tell maven-bundle-plugin to export all of the dependencies packages
I left some things blank that you have to set like library.groupId, library.artifactId and library.version. And somethings we need to tweak the configuration of the maven-bundle-plugin. But this is our starting point. Somethings for example, you do not want to export all packages etc.
If you really have 100+ dependencies that you need to convert you might be better of using this template and just adding all of your 100 dependencies as dependency and build one big bundle with all of them inside.
You can find the documentation for the maven-bundle-plugin here:
https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
At this point I also want to mention that there is a new bundle plugin that you might want to consider for this: bnd-maven-plugin.
See: https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin
I am using MultipartbodyBuilder to send file and metadata from a REST web service client. To use
In my pom file I have added
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.3.2</version>
</dependency>
and also
<Embed-Dependency>
http-mime
</Embed-Dependency>
I have not added any bundle related to mime to this feature in the applications feature.xml
When I try to install the feature on karaf I get the following error in log files and it goes in Waiting
->net.sf.cglib.core.CodeGenerationException: java.lang.StackOverflowError-->null
2016-08-03 20:10:22,456[SpringOsgiExtenderThread-58]|ERROR|org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean|175-org.apache.cxf.cxf-rt-frontend-jaxrs-2.7.3|net.sf.cglib.core.CodeGenerationException : java.lang.RuntimeException-->net.sf.cglib.core.CodeGenerationException: java.lang.StackOverflowError-->null
I am using karaf osgi so I figured that I need to have a osgi bundle mapped to features.xml http mime is a jar without any bundle. There is a httpclient osgi bundle but it has other dependencies and it breaks my other projects mapped in features xml.
I want to know how to create an osgi bundle using httpmime 4.3.2 jar file. I am new to this so if some guidance and reference will help.
There is a karaf feature called wrap. This allows you to use also non OSGI jar files. In your feature.xml you just need to add the following bundle to your feature.
<bundle>wrap:mvn:org.apache.httpcomponents/httpmime/4.3.2</bundle>
We are adding new code to an existing project that uses a custom build system developed with Ant and Ivy for dependency management.
Our new team is used to Maven and its features like testing execution, cobertura reports, etc.
Our question is: is it viable to add a pom.xml matching the current project structure, but instruct Maven to load its classpath from the "lib" dir already filled by Ivy?
In other words: we want to use Maven without its dependency management.
One really dirty approach would be to generate one big jar from the libdir and config the pom.xml to include just that... but we believe there should be cleaner approach.
Any idea or recommendation?
Note: we are not interested in generating a pom.xml with dependencies from the Ivy config, we just want Maven to rely on Ivy's generated classpath. No need to discriminate between test/runtime/compile classpath.
This is our final setup to solve this:
For each Ivy legacy project, use ivy:makepom and manual inspection to figure out the dependencies that we need to send to the new projects (Maven-based). This is a one-time process for each project.
Modify the legacy build system in a way that, every time a project is built, the identified dependencies are also exported to a mvn repo. Because de build machine holds the internal repo, we just use mvn install.
In the new maven projects, declare each dependency in the pom.xml and make sure the build system runs maven builds after the legacy builds.
Thank you all for your help!
One possibility is to use the system scope to define your dependencies in maven. This allows maven to use the jars downloaded by ivy for its dependencies.
e.g.
<dependencies>
<dependency>
<groupId>group.id</groupId>
<artifactId>artifact</artifactId>
<version>a.b.c</version>
<scope>system</scope>
<systemPath>${basedir}/lib/artifact-a.b.c.jar</systemPath>
</dependency>
...
</dependencies>
Maybe the makepom task will be helpful, it creates a pom from the ivy file.
Example from that page:
<ivy:makepom ivyfile="${basedir}/path/to/ivy.xml" pomfile="${basedir}/path/to/module.pom" conf="default,runtime">
<mapping conf="default" scope="compile"/>
<mapping conf="runtime" scope="runtime"/>
<dependency group="com.acme" artifact="acme-logging" version="1.0" optional="true"/>
</ivy:makepom>
I came across this question when trying to share the Struts packages among multiple bundles inside an OSGi container. I wanted to avoid both duplicating dependencies inside the bundles and introducing a new dependency between them (by having one bundle export its internal dependencies for the other to share).
It turns out the answer is very easy if you happen to use Maven, and if you aren't, you can still use the Maven solution to learn how to create the same result with some other mechanism.
I found this approach useful multiple times during my project, so I'll post an example here.
An additional path for those not so keen on maven, unable to port, or perfectly happy with ant/ivy
I've found the that easiest way to accomplish the stated task is to turn the non-OSGi library into an OSGi library by letting the manifest export every package and add on some approriate symbolic names / versions. I've been able to do this VERY easily with bnd via ant tasks (or even direct command line invocation). There are also repositories which contain "osgi-ified" version of many popular libraries. Some libraries (joda-time) are already shipping with correct OSGi manifests.
Using Maven, it is very easy to create an OSGi bundle from any library. However, I think the same result can be created with other mechanisms, too. The Maven solution helped me understand how it works.
Creating the bundle is done by creating a project which has the library as a dependency and then packaging the project using the maven-bundle-plugin from the Apache Felix project and specifying the library packages with the Export-Package instruction. I used this to share Google Protocol Buffers between bundles inside an OSGi container:
<?xml version="1.0" encoding="UTF-8" ?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.lib</groupId>
<artifactId>protobuf-dist</artifactId>
<version>2.1.0</version>
<name>Google Protocol Buffers OSGi Distribution</name>
<packaging>bundle</packaging>
<dependencies>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.1.0</version>
<scope>compile</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>com.google.protobuf</Export-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
If you want all transitive dependencies rolled into the bundle, too, use the bundleall goal of the plugin.
The plugin recognizes and honours existing OSGi manifests in the dependency.
You can also use the bundle plugin to just create the manifest and tell the jar packaging plugin (or the jar-with-dependencies builtin assembly) to use that manifest via the archive section. The plugin's page linked above shows how to do that.