I have a bunch of java classes and a bundle activator class that I need to deploy to karaf.
I see that the karat-maven-plugin has kar packaging and karaf-assembly.
Also it generates features.xml
I can generate features.xml directly and it generates lines with wrap: for some of my dependent non-osgi jars.
But when I run karat-assembly, I run into the issue of the assembly goal not realizing that these jars are not osgi and end up with errors.
What it the recommended way to get a custom karaf with my application installed ?
Does the karat-assembly packaging need to have a features.xml generated and provided beforehand ? Or is it supposed to do the feature set generation by itself ? If it is the latter, then how do I get around the problem of the karat-assembly not recognizing non-osgi jars ?
I have spent a LOT of time with google and am stumped.
This is my procedure for creating a custom karaf distribution. It may not be "best practice" but it works for me. Maybe you can customize for your needs.
After developing my Camel routes and testing I generate my feature file based on a feature template found in /src/main/feature/feature.xml. The karaf-maven-plugin will generate the feature will in the feature folder inside /target.
I do a clean deploy to our maven artifactory.
I have a custom Karaf project do a clean install on that project. The project has dependencies to the initial project and I add all the features as boot level feature.
Once build I unzip the distribution and run the Karaf app. If everything looks ok its ready to be shipped.
Related
I have a mission to develop an integration tool which allows from a source code folder to generate a WAR or OSGI Bundle and then deploys it in Tomcat or Karaf. I used Maven Embedder to create the artifacts, now my problem is how to configure my pom.xml to automatically deploy these artifacts.
on the internet I can't find any examples and also I'm new to the world of JEE and Maven.
please help me.
Find out how you can deploy artifacts to Tomcat or Karaf (without Maven).
Find out how you can deploy artifacts to Tomcat or Karaf programmatically.
Find a Maven plugin to use that deployment method.
The simplest solution would be to use something like the maven-resources-plugin to copy your built artifacts to the servers deployment directory but I am pretty sure that there are more sophisticated methods like http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/deploy-only-mojo.html for deploying out of maven without plain file system mechanisms.
On a wider scale when working on problems like yours it always helps to take a step back and think about the abstract use case ("How to deploy something somewhere" followed by "How to deploy something somewhere programmatically") before going into detail and think about Tomcat or other application servers - and in most cases you will find out that there were hundreds of other who already had the same problem and solved it some way or the other.
We have a very big web application containing many features.Now for maintainability we want to split the application in components so that can remove / add particular components (jars). For that one suggestion is coming is to use OSGI. I think converting jars into bundle will take huge effort. I think same functionality can be achieved by Maven. According to my understanding OSGI is packaging tool. If I can make Maven plug-in for each component then any particular component can be included or removed at compile as opposed to run time as in case of OSGI.
Modularizing the application using Maven will be simpler than OSGI. I have read similar post on this site and it commented that OSGI and Maven are like comparing apple with orange. But I think in one sense both are same as they both meant for packaging difference is one is used at run time and one for compile time
Looking forward for well though answer :)
best wishes
Shailesh
As you already hinted at yourself: you're comparing apple with orange.
OSGi is not a packaging tool.
OSGi bundles are plain JAR files with some OSGi-specific metadata in the Manifest file.
You can create OSGi bundles using Maven e.g. using the Maven Bundle Plugin (I can recommend this approach). So regardless if you're using OSGi or not I strongly recommend using Maven.
Here some use cases for OSGi:
You want to create different versions of your application e.g. for different customers. With OSGi you can just add/ remove bundles without having to touch any other configuration.
You need a plugin system so 3rd parties can provide plugins to your application
You want your application to be truely modular
You want to share some code with other applications but want to hide some internal classes
...
OSGI is much much more than a packaging tool. You could say that OSGI has a packaging tool inside. Maven is a packaging tool and a dependency manager. I'd say that, given the level of complexity and the use you say you'll make of this technology, go with Maven.
A little back ground: We are using Apache Felix implementation of OSGI for our web development (Adobe CQ5 which inturn is built on apache felix). We have a few bundles of our own (around 10) and each of them are configured as a project.
Issue: During the development lifecycle, we make changes to a bundle and then use an ant script to create the bundle and deploy it in the felix. I am wondering if there is some way to enable hot deployment of the changes I make during development mode that would save developers time.
Based on my research, we can use the felix file install which will monitor a folder(s) for changes to any bundles and can deploy them automatically. But this again means I need to run ant script to build the jar file and move it to the auto deploy folder the file install is watching. Is there a better/fast way to achieve this? The script is currently taking a around 10 seconds (approx) to compile the classes, create osgi specific meta data files, bundle the classes+metadata in a new jar. Is there some way to do hot deployment, so that any change I make to a java file is automatically reflected in the bundle?
Many thanks
If you develop your project in Bndtools, and run from the built-in launcher, then Bndtools will handle immediately building any Java code that you change, and deploying the updated bundle into the runtime. This leads to an extremely quick code/test/debug/fix cycle.
Having said that, I'm amazed that it takes 10 seconds to compile and build your bundles currently! Are you building on an extremely ancient computer? Or is the bundle multiple gigabytes in size?
We tried DCEVM and it does almost everything we expected to reduce the develop+fix+test life cycle. I recommend this to all java developers using big web applications. Thanks for your suggestion on bndtools Neil.
I'm building an Eclipse plugin using Tycho and am making use of Declarative Services for my OSGi services. Eclipse has a nice Editor for DS files, but it still is a manual process, which means it's slow and error-prone.
In non-Tycho OSGi projects I can use the maven-scr-plugin to generate these annotations. The catch with Tycho is that I can't add a reference to the org.apache.felix.annotations jar since it's
not present in a p2 repository
not a bundle
These annotations are defined with a RetentionPolicy = CLASS, so they don't have to be in a bundle.
I know about dependency on pom-first artifacts, but it's not going to work for me since the annotations jar is not a bundle. Ideally I could just configure Tycho/Eclipse to look for an extra jar just at compile time.
How can I get a compile-time only jar considered by Tycho and Eclipse?
Update: I've tried to use the extraClasspathElements option of the tycho-compiler-plugin. That does allow me to invoke the maven-scr-plugin (see the current pom.xml). However, it seems that the scr plugin can't access the classes, as the build fails with
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.13.0:scr (generate-scr-descriptor) on project org.apache.sling.ide.eclipse-core: /mnt/md/robert/git/sling-ide-tools/eclipse-core/src/org/apache/sling/ide/eclipse/core/ServerUtil.java : Unable to load compiled class: org.apache.sling.ide.eclipse.core.ServerUtil
You can also see the full build log
Since you are using Tycho/Eclipse, you probably want to use "org.eclipse.equinox.ds" rather than "org.apache.felix.annotations". If I understand correctly, org.eclipse.equinox.ds is a bundle. The Tycho FAQ mentions this as well:
http://wiki.eclipse.org/Tycho/FAQ#How_to_add_a_undeclared_dependency.3F__.28e.g..2C_OSGi_declarative_service.29
EDIT:
http://eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html#extraClasspathElements
EDIT2: A lot has changed. I'll be updating my answer when time permits. Check the comment threads in the meantime =)
I think the best you can do is to separate your building in two steps.
One for building the felix (scr/bnd) based bundles. the result will be on a local maven repository and all will be already bundles with the manifests and component xmls.
As the annotation is processed only at building time you won't have any problem with the following step.
The second step is to build the tycho based artifacts(bundles,features,rcp,p2,etc) that will consume the bundles in the first build.
I had this crazy idea since a long time so decided to finally ask. Is there some project for integrating bundles directly into the the build process without explicitly doing extra work of including an osgi container and adding bundles etc. So the basic idea being in you build.sbt or pom.xml you just specify your dependency like you normally do and instead of fetching the jars, sbt or mvn fetches bundles (if available) for your dependency. And on building the project a container of your choice would be downloaded and bundles (and jars) would be added to it automatically ? Just like a fairy tale.
EDIT: By the last part i meant something along the lines of felix gogo which will create a script for adding bundles to run container with them. Althogh thats too much to ask for but after the build i can just run a script and my whole project will run on an osgi container free from jar hell.
This already works today. You simply use the maven bundle plugin to create a bundle of your code during the build process. Many of the jars in maven central already are bundles. So you just specify them as normal dependencies.
I am not sure what you want to achieve in the last part. Downlaoding the container and adding the bundles. The build process just creates the jar. Why should it load a container?
If you want to do this for testing purposes then pax exam is what you search. It does exactly what your describe for your unit tests. It downloads a container, adds your bundles and deploys and runs your test in the container.