I'm using Bndtools in Eclipse IDE. It's great and works fine.
I'm able to add osgi.core package into the "Build Path" editing the bnd file (it uses the bndtools repositories).
Now I need the org.osgi.util.tracker package but I can't find it in the "Build Path" editing the bnd file.
How can I do it ?
Thanks,
Paolo
org.osgi.util.tracker is a package but in the Java compiler we need to put whole JARs on the build classpath.
This package happens to come from the bundle/JAR called osgi.cmpn, which represents the OSGi Compendium specifications. So just add osgi.cmpn to the -buildpath of your bnd.bnd file and the package you want will be visible.
If you don't know what JAR/bundle a package comes from, you can use the Advanced Search button in the Repositories View in Bndtools. If you can't find it there then you will have to go and get the JAR from the outside world and import it into your repository. Just googling for the package name will usually tell you the name of the library you need.
If you use [OSGi enRoute][1] then you'll find that you only need to compile against the base API JAR (all enRoute projects are so setup). This makes your life a lot easier. The base API contains all API (and ONLY API) for the most common tasks from the most humble 'Hello World' to a REST server with Web User Interface.
[1] http://enroute.osgi.org
Related
I am currently starting my adventure with Maven, and I actually don't understand the idea behind using it to automate compilation of my source code. For the time being I am working on small projects with up to 15-20 classes, and 1 main method in the "app" class. Could someone please give me the explanation with examples, when it's necesarry (or recommended) to use build automatation tool to compile the source code and how could I benefit from using it regarding source code compilation?
Thank you very much in advance!
I was looking for different answers and I have a lot of work to do but since I've seen this question, as a Maven fanboy, I couldn't resist anymore and this below is my answer.
First of all, I agree with JF Meier which answered before me, but I think the answer can be improved.
IMO you have to consider Maven not just as a build tool, but as a multi-purpose tool which can help you to do very different things. The best 3, for me are:
Compiler. Obviously. Maven allows you to easily compile giant projects with a lot of submodules, even if some of these modules are interdependent one with each other.
Dependency and repository manager. Maven allows you to automatically download third party software and bind this downlaod to the build. This is immediately understandable if you think to framework or api dependencies from big corps (Apache found., Spark, Spring, Hibernate and so on ...) but it's really powerful in every enterprise context.
Example: you have a Maven project (let's say project A) which manages requests coming from a webservice and provides responses. This Maven project relys on another Maven project (let's say project B) which actually generates webservice jar and uploads it to a company repository. Well, when you have to add a field or a method to the webservice you just have to implements new software in project B, upload it the repo and change the version in Maven poms in both project A and B. Voilà: now EVERY developer of the company just have to "mvn clean install" project A to have the new version.
Sources and code automatic generator. Since Maven 2.x are available a lot of plugins (from Apache found. and others) which allow you to generate code and sources (tipically xml files) starting from little to none implementations.
Example 1: CXF plugin is commonly used to generate java classes from xml or xsd files.
Example 2: JAXWS plugin is commonly used to generate wsdl from SOAP webservice implementations or implementation starting from wsdl file.
Do you feel the power now?
-Andrea
The question is not very specific, but I will try to answer.
Usually, you want your source code to end up in a jar or war, so that you can use it as a library or run it somewhere (e.g. on an application server).
Maven not only compiles the classes you have and creates the final artifact (jar, war), but also handles your dependencies, e.g. the libraries your project depends upon.
I am working in a OSGi project where we need to export a package in bundle but we do not want to export a two specific class of this bundle. To give more background, we use a third party jar that is not osgi bundle so we add this as a part of OSGi bundle and in this third party jar we need to export a package "A" but this package A has two specific classes that we do not intend to be exported. Please give your suggestion on the way to achieve this.
Export-Package: some.package.name; version=1.0; exclude:="ClassA,ClassB"
See sections 3.6.5 and 3.7.9 in the OSGi Core specification.
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
I'm creating a java command line project, with no GUI. The project uses any number of open source projects : Spring, Logback, Commons CLI etc.
When I started to think about packaging, I imagined it would come out as a zip file, that could be exploded to the jar, with a lib sub directory, and dependent jars in the lib.
adapter.jar
/lib/dependencyA.jar
/lib/dependencyB.jar
etc.
I've been playing with Maven Assembly, but it's still not coming out like the above, and I haven't found any examples that do generate the structure above. Is it possible to do so ?
In addition, having a multi-module structure adds another layer of complexity that I haven't been able to resolve, as the assembly module can't find the core module as a dependency. This is my first Maven project, so am still learning how Maven works. I've been through the Sonatype book, but missed something as even using the Best Practices section couldn't get the missing dependency resolved.
The examples I've seen usually involve merging into an uber executable jar, some of which use the Shade project, some don't. My question is, is doing an uber jar including 3rd party libs like Spring etc a good idea ? Or should I persevere with my original zip / lib subdirectory plan ?
Have your assembly module depend on the modules you want to package and then use the <dependencySets> of <moduleSets> tags to include them in any layout you wish. If you have some other files that do not come from a dependency, you can put them in the deployment module itself.
Please have a good read on the assembly descriptor docs. You can pack, unpack, include/exclude and set permissions for the files in your assembly.
In case you haven't seen the sonatype book on maven, here is the relevant chapter: http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-best-practices.html
EDIT: escaped the <'s
You just need to be more specific in your assembly descriptor. Use one dependencySet that includes only the main jar and delivers it to the top, and another that excludes only the main jar and delivers to the lib dir.
Currently I'm working on open source project.
There exists bunch of java classes which are simple examples.
How should I organize this project with maven. Should I provide some packaging for them ?
Put the examples in a separate project and add your main project as a dependency. Package them according to what kind of code they are. (e.g. if the samples build a webapp, make the packaging a war)