I'm working on a project, it's integration project, we are using Apache Camel and Apache Karaf.
In the project, I need to use the Jira REST Java client library.
So I've read quite a lot of various articles and threads about how to wrap non-OSGI library to OSGI bundle, but I'm really not sure if I got it right.
So, I've created a POM file with a dependency to the needed library. Made a package and tried to deploy it to Karaf, of course, Karaf complained for missing packages.
So, I've found corresponding maven dependency, added it, package goes into <Import-Package> and dependency into <Embed-Dependency>.
Another round, deploy, find dependency, add, ... and again, and again, until Karaf is fine with the bundle.
Is that really correct? It seems to me like quite crazy, so I guess I don't got it as usualy :)
Finally, the package get to stable that was on my work computer, I checked it quickly and went home, there I continued but, strange, the same POM / package, compiled on my personal computer is not working, again complaining about missing package, but this time, this package is for sure in the POM file and for sure it is embeded in the package, I can see it there.
This missing package is this time org.apache.commons.codec.
org.osgi.framework.BundleException: Unresolved constraint in bundle jiraclient.bundle [134]: Unable to resolve 134.0: missing requirement [134.0] osgi.wiring.package; (osgi.wiring.package=org.apache.commons.codec)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)[org.apache.felix.framework-4.0.3.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1208)[6:org.apache.felix.fileinstall:3.2.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:503)[6:org.apache.felix.fileinstall:3.2.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6]
So, now I'm totally confused, what is wrong :(
Pretty please, guys, help me. Thanks!
The POM file is long, so I guess link is better: http://pastebin.com/j5cmWveG
Yes OSGi is IMHO "far from easy to use" in terms of its deployment model, requiring 100% bundles with osgi metadata in MANIFEST.MF files. And you need a PhD in mathematics to understand the BND tool. And unfortunately many JARs are not OSGi bundles.
Looking at your pom.xml file with all the imports|exports, and that "not easy to understand" syntax, would just take 5-sec for any average engineer to understand that this "something is wrotten in the state of Denmark" ; eg OSGi != the world we live in. This must and should be easier IMHO.
You can install a plain JAR in Karaf using the wrap url handler:
http://karaf.apache.org/manual/latest/developers-guide/creating-bundles.html
Another trick is to create an uber JAR, eg to put it all in a single JAR file and then you can deploy that.
There is also FAB (Fuse Bundles) which makes OSGi deployment easier, as it handles much of this craziness for you at deploy time, instead of you having to deal with the OSGi MANIFEST.MF madness: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
Related
I'm trying to parse WSDL files using the EasyWSDL library on my (atlassian) maven plugin project. I keep getting this error when I try to parse the file and it fails when the project tries to reach the TransformerFactoryImpl class from said "xalan" package. The package is located inside the JDK, so it's supposed to be available to runtime, yet for some reason it can't reach it.
I've tried importing the package through
<import-package>com.sun.org.apache.xalan.internal.*,</import-package>
section of the pom.xml, but that gives me the following error:
Unresolved requirements: [[my.plugin.package [304](R 304.0)] osgi.wiring.package; (osgi.wiring.package=com.sun.org.apache.xalan.internal.xsltc.trax)]
Which makes it seem like the other packages of xalan are found, except for the xsltc.trax one.
I've tried creating a bundle extension for OSGi that exports this one package and exposes it to the classpath but due to lack of experience and pretty poor documentation on that matter I can't get that working either. Adding Xalan as a dependency and using <scope>provided</scope> does nothing as well.
I need to find a way to put this specific package on the classpath when the program is running. When I run unit-tests on my implementations they work just fine, so it seems to purely be a runtime classpath problem.
Is there anyone with experience on this matter? I've little experience with OSGi, and my experience with maven isn't huge either. So I'm hoping it's something I did wrong myself instead of this being an impossible problem to solve.
I'm trying to build an application that uses an embedded OrientDB (currently "memory:") graph database.
I'm using OrientDB 2.2
I am using Eclipse bndtools for my development environment.
I have added orientdb-core and orientdb-graphdb osgi bundles as build dependencies to my bundle, but on its own that isn't enough, I need access to the tinkerpop blueprint classes as well. There doesn't seem to be a tinkerpop blueprints osgi bundle that I can see.
I can include the blueprints-core jar as a build dependency, and that gets rid of the compile errors, but I then get into all sorts of issues trying to resolve the bundles so I can run something. (the primary error there that I don't seem to be able to get rid of is a complain about not being able to resolve "com.carrotsearch.hppc" -- I include that in my bundle, and export it, but still no joy there)
Shouldn't orientdb-graphdb either depend on a suitable bundle, or include and export the classes?
It sounds like you're running into the classic problem of wrapping a third-party, non-OSGi library as an OSGi bundle.
The best tutorial for this is on the EnRoute site. Note that you don't need to be using EnRoute for this tutorial to be relevant.
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.
There are two main approaches when developing an OSGi application with Maven: POM-first and MANIFEST first.
I'm looking for an answer that is in a form of a table that shows pros and cons of each method.
To be more specific, I would also like to know how it relates to:
Maturity of toolset
Vendor independence
Development ease (which includes finding people who can do the development on the tooling)
Compatibility
Avoiding ClassNotFound
Avoiding manual work
At present this is what I can come up with
POM-First Pros (using maven-bundle-plugin)
Leverages existing Maven skills, repositories and tooling.
Likely easier to find people who know how to manage pom.xml rather than MANIFEST.MF along with pom.xml
Most of the information in MANIFEST.MF can be obtained from the pom.xml itself.
Can work with other IDEs not just Eclipse based ones.
Less invasive, just add the single plugin and change the packaging type to "bundle"
POM-First Cons
ClassNotFoundException more likely to occur at runtime. However, this can be mitigated using pax-exam (although it is very complicated to set up).
Still need to understand how the MANIFEST is setup to make sure the instructions configuration element is set correctly.
MANIFEST-first Pros (using tycho-maven-plugin)
Seems to be the recommended approach, or at least talked about as the recommended approach, but I can't really see why it has significant benefit. (Hence why this question was asked).
Good for developing Eclipse plugins and integrates well with PDE
Provides tooling for testing thus allowing ClassNotFoundException to appear during JUnit testing rather than runtime.
MANIFEST-first Cons
Seems to only work well on Eclipse based IDEs. You don't have to use Eclipse, but without the PDE would you want to?
Violates DRY principles since I have to do put keep the names and versions from the POM and MANIFEST.MF in sync.
Need to name things in a specific fashion
You cannot mix, meaning existing Maven multi-project installations cannot just tack on OSGi support
A lot more configuration compared to maven-bundle-plugin is needed to get less warnings: http://wiki.eclipse.org/Tycho/Reference_Card#Examplary_parent_POM
Have to make test cases a separate project. It won't run when built in src/test/java.
Seems that it will only test classes that are exposed, in other words those in ".internal." is not testable.
If I were asked for a recommendation for an enterprise that is using Maven already and want to move to OSGi then it would be POM first
If I were asked for a recommendation for someone who is doing Eclipse plugin development, then it is Manifest first -- with tycho
I think you should choose by use case. For server side OSGi projects I favour the pom first style. It nicely matches the maven builds and is much less error prone than Manifest first.
In fact bnd which is behind the maven bundle plugin gets the Manifest right for most cases without any additional config. The trick is to use some naming rules. For example if you name internal package impl or internal the will not be exported. Using this style you can not use the Eclipse plugin perspective (at least without bndtools which I do not like) but I did not yet miss this perspective. I am a developer in the Apache Karaf, CXF and Camel projects where we use this style and it works great. Especially for CXF and Camel it is great that we can support OSGi and non OSGi deployments with the same build and tools.
For Eclipse RCP applications Manifest first is the way to go as you need the plugin perspective and the Eclipse IDE tools. If you want to combine that with maven then tycho is probably the way to go.
MANIFEST first does not lock you to Eclipse (although I'd be surprised if more than a tiny minority would use anything else). The MANIFEST is the file that counts, and needs to be added to a jar, regardless how you do that.
On the other hand, POM first completely locks you to Maven, you lose the advantage that an OSGi bundle is a regular jar you can make any way you want.
I've tried both, I really prefer MANIFEST first. The MANIFEST file is a really important file, I prefer to craft that file over crafting a file that produces that file. If something weird happens, (and it will at some point) the MANIFEST file is the first to check, it's just easier if it's your own file. Besides, you will have to be familiar with it anyway.
So, if Maven is your alpha and omega, POM first will suit you best, but you'll still need to have in-depth understanding of the MANIFEST file.
I have been assigned a job to compile an old Websphere(WAS4) project, so we can find out which parts of it need to be changed for the project upgrating( to WAS7).
But when I was trying to fix the jar errors, wesphere.jar is missing!! And WAS7 installation path never hava this jar anymore, searching google failed. And I don't like to install older WAS again to just get this jar.
please anybody can help with this, providing an WAS4 version webspere.jar???
TKX in advance!
The jar file itself isn't important, the classes within it are. I don't recall what was in websphere.jar, but there's a good chance that what was is now in j2ee.jar. In fact, if your code isn't using any WebSphere-specific extensions, there's a good chance j2ee.jar is the only jar from WebSphere that you'll need for compiling.
But you should be able to see what specific classes are being complained about by the compiler and if necessary search for those by opening the jar files in like WinZip.
(Keep in mind that the larger changes are the changes to J2EE and Servlet specification levels.)