I'm new to osgi and wonder if it is possible to have a centralized mechanism to update, install or remove bundles.
Yes. You can do this programmatically, which means there are a large number of bundles that provide you out-of-the-box solutions. It is so easy (and so much fun) that for many people one of their first bundles is a little "management agent" (as the OSGi specification calls this part).
The absolute simplest solution is Apache File Install. It tracks a directory and installs/uninstalls from there. Couple this to Google Drive or Dropbox and you have a large scale fully automated deploy model (it also handles configuration, which is quite important).
The OSGi specification now has an OSGi Bundle Repository (OBR) specification. This is a very powerful model to describe dependencies (not just bundles) that allow management agents to calculate/leverage dependencies. This is supported out of the box on Felix.
There are a myriad of solutions that manage OSGi frameworks. There is commercial support with Paremus, IBM Tivoli, ProSyst and many others. And open source with Apache ACE and fusebundles.
There are two general ways to do that: Have you application to 'pull' bundles from a repository hosting bundles and update itself, or have an external provisioning application 'push' bundles to your application.
For pull solutions I'd say there is:
Eclipse P2 Used by the update manager of Eclipse. Mature, stable, but can be a bit tricky to get into, also I'm not sure if P2 works with other OSGi runtimes than Eclipse Equinox
Apache Bundle Repository (OBR) A bit easier, and it's in the OSGi spec.
For push solutions I'd say have a look at Apache Ace, from your question I think that is closest to what you want to do.
Related
I am stuck with a problem I can't solve for weaks now.
I have to create a modular JavaFX application, where each component defines a "domain unit" (with models+views+controllers). Each component can be loaded into a "shell application" (as a content of a tab view or multiple tab views) and the modules can depend on another module(s) (their content in tabs won't appear if their dependency is not loaded).
That's why I was planning to create an OSGi based JavaFX application and build it with Gradle as a multiproject.
I've already tried dozens of tutorials with no success and I experienced, that most of these tutorials:
are outdated, not reproducible (e.g. elcipse's interface, templates have changed, bndtools tutorials doesn't seem to work, equinox doesn't seem to to work without felix, javafx8+osgi generate different kind of problems... etc.)
are too complex for a beginner (I just started to learn OSGi and Gradle) and they skip important steps I am not aware of
contain too much "IDE magic" (I would rather type some code instead of filling forms in eclipse)
some solve the problem with different tools (maven/tycho, bndtools, e(fx)clipse), but I've got no time to learn them
I want my application to be independent from IDE's environment. I don't want to use e(fx)clipse or BndTools if possible (even if they can make the build process easier)..
I'm experimenting with OSGi implementations, that's why I would rather not to choose between Equinox, Felix or Karaf.
I've already programmed similar application in .NET world, but it seems to me impossible to do the same in Java world..
My main questions are:
is it possible to do what I have imagined?
how to create a gradle multiproject what is IDE/platform independent (if projects are not tied to eclipse environment, or equinox, but it's possible to use them)?
what are the best ways to initialize the application (shell application + modules) and load the independent modules/bundles/components?
how to separate my views into subprojects (what build.gradle files should contain)?
how to solve the javafx8 inpompatibility with osgi?
what is the correct way to apply javafx plugin in gradle?
what tutorials are the most relevant?
is there any working example, pattern or tutorial (without using additional tools) what solve the same problem (using only osgi+javafx+gradle)?
I could group your questions in differents topic:
OSGI
You just need to google around to find out that is a java specification that encourages modularization, provides hot-deploy feature, and so on. As I told you, is just an specification like Java Servlet API, so they are different providers or implementers of OSGI Specification such as Felix and Equinox. Karaf instead is a OSGI container based on Felix, so you get all felix benefits and in addiction karaf natives features. For that reason I encourage you to take Karaf into use.
Aquote BndTool
In order to satisfy the OSGI specification, you need that your modules contains a MANIFEST.MF which holds all dependency information so Karaf create the classloader required for your bundles.
Assuming that you don't want to create that MANIFEST.MF files by hand, you could take aqute/bndtool for that. Don't get mess with bndtool for eclipse plugin. That application can be used from command line, from a maven plugin, or from a gradle plugin. Basically scans your classes, check the imports, and create a MANIFEST.MF automatically.
Gradle
If you choose gradle as a build tool, then you can take into use: Bnd Gradle plugin. It's easy to set up, but follow the instruction for non-workspace plugin. If you don't want to use BndTool for eclipse. IDE independent solution, you mentioned in your question.
MultiProject Layout
How the project layout should look like, depends on your modularization, but you can have a look on this layout example that uses gradle+osgi+karaf for a multiproject. Perhaps inspires you.
https://github.com/antoniomaria/gradle-karaf-bnd-project
I have used Eclipse for some time (just for general java development) and now I am trying to understand the added features that STS brings, and also learn Spring Boot development. I see that when I create a Spring Boot project it always wants me to select Maven or Gradle as the build tool but I'm not sure why or what that does.
I just don't fully understand what Maven is doing when I'm working in the environment. Eclipse always compiled the code and did other things for me by invoking the compiler and I never needed an external build tool like ant or Maven or whatever.
So is it just making a Maven configuration in case I want to build the application outside the Eclipse environment or does STS rely on an external build tool?
For small, "Hello world", projects simple Eclipse compile/debug is more than good enough.
Maven is "higher level" than "make/makefile" (the classic C/C++ build tool) or "ant/build.xml". Specifically:
Why maven? What are the benefits?
Henning:
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to
centralized POM.
getting a number of reports and metrics for a project
"for free" reduce the size of source distributions, because jars can
be pulled from a central location
Emmanuel Venisse
Lot of goals are available so it isn't necessary to develop some
specific build process part contrary to ANT we can reuse existing ANT
tasks in build process with antrun plugin
Jesse McConnell
Promotes modular design of code. by making it simple to manage
mulitple projects
it allows the design to be laid out into multiple
logical parts, weaving these parts together through the use of
dependency tracking in pom files.
Enforces modular design of code. it
is easy to pay lipservice to modular code, but when the code is in
seperate compiling projects it is impossible to cross pollinate
References between modules of code unless you specifically allow for
it in your dependency management... there is no 'I'll just do this now
and fix it later' implementations.
Dependency Management is clearly
declared. with the dependency management mechanism you have to try to
screw up your jar versioning...there is none of the classic problem of
'which version of this vendor jar is this?' And setting it up on an
existing project rips the top off of the existing mess if it exists
when you are forced to make 'unknown' versions in your repository to
get things up and running...that or lie to yourself that you know the
actual version of ABC.jar.
Strong typed life cycle there is a strong
defined lifecycle that a software system goes thru from the initiation
of a build to the end... and the users are allowed to mix and match
their system to the lifecycle instead of cobble together their own
lifecycle..
this has the additional benefit of allowing people to move
from one project to another and speak using the same vocabulary in
terms of software building
At an even higher level, Maven is a preferred build system for organizations interested in "ALM" ("Automated Lifecycle Management"), "CI" (Continuous Integration"), "CLM" ("Continuous Lifecycle Management") and/or "Devops":
https://www.ibm.com/developerworks/community/blogs/nfrsblog/entry/DevOps_best_practices_a_6_part_series?lang=en
DevOps (a clipped compound of "development" and "operations") is a
software development method that emphasizes communication,
collaboration (information sharing and web service usage),
integration, automation, and measurement of cooperation between
software developers and other IT professionals.[1][2] The method
acknowledges the interdependence of software development, quality
assurance, and IT operations, and aims to help an organization rapidly
produce software products and services and to improve operations
performance.
For "serious" projects, your organization (consisting of many developers, possibily distributed geographically) will integrate your project with a DevOps toolkit like Sonatype Nexus or Artifactory. Which, in turn, typically use Maven to automate project build and runtime dependencies.
But even for relatively "simple" Spring projects, you'll probably learn to appreciate the convenience Maven can bring to your builds (and corresponding JUnit tests).
I am new to the OSGI world and could use some advice from the experts out there. My aim is to deploy a few servlets along with REST resources into a standard Karaf installation. I am planning to use Grizzly (w/Jersey) as the http container.
I am trying to figure out a way to create an eclipse project, in which I can compile my custom code, and deploy this code along with all dependencies such as Grizzly, Jersey, OSGI frameworks & bundles as a single archive into Karaf.
The end goal is to have a single deployable entity which includes all my code and the dependencies without needing to manually install dependencies in Karaf.
Is this possible or am I looking at it the wrong way? I have been reading up on OBR, features and KAR but not able to put the whole picture together as yet. What would be the best practice wrt achieving this objective?
Thanks!
To give you the general idea regarding embedding and launching a complete OSGi application, I suggest you check out chapter 13 on this book. It explains it using Equinox implementation but I hope the overall approach should look similar. If you follow through you will see that you can put all your bundles in a folder where the system will iterate through and install them.
In Dependencies tab, I have a choice between plug-ins and packages.
What's the difference between them? For org.eclipse.compare, I have it in imported package and also in plug-ins.
I find the jar file in plugins directory, but I don't know where the package file of org.eclipse.compare is located.
In the export menu, it seems like that there seems to be only exporting to jar, not exporting a plugin or packages. How can I export packages?
ADDED
Based on this post - How to import a package from Eclipse? and shiplu's answer. This is what I came to understand. Please correct me if I'm wrong.
In eclipse, when I use come external class, I can use Quick-Assistant or Organize imports (Ctrl-Shift-O) to resolve the reference. Eclipse adds the package that contains the class in Imported Packages for the project that I'm working on. A package can contain multiple classes (types). Eclipse understands what plugin contains the package, and resolve the reference issues.
A plug-in (jar file) can contain multiple packages. By specifying a required plug-ins in the dependencies tab, we can reference all the packages (and classes in the packages) for all the java projects in the eclipse IDE.
And from my experience, I had to add all the dependencies in order to make headless RCP standalone (http://prosseek.blogspot.com/2012/12/headless-rcp-standalone.html).
An Eclipse plug-in is basically an OSGi bundle with additional plugin.xml file which Eclipse IDE understands and interprets.
So the answer to your question lies in the OSGi specification and the OSGi programming model, since, very simply put, Eclipse is an Application running on implementation of OSGi called Equinox.
OSGi is all about having modular applications and so it defines several levels of modularity.
One such level is a bundle-level (module-level) modularity and more fine grained level is the package level modularity.
So you can have your OSGi application (a set of bundles; eclipse is just that) which consists of db-bundle (which provides data store services), app-domain-bundle (which provides your application domain services) and remote-bundle (which exposes to the web your application via REST for example).
And then you say remote-bundle depends on domain-bundle which depends on db-bundle.
Which is all good, but cripples the inherent modularity OSGi provides, because you are basically restricting your application to specific implementations of db-bundle and remote-bundle i.e. to specific implementations of the services they provide.
Instead, you can establish the above dependencies not between bundles but between packages i.e. establish a service-level dependencies.
Then you say domain-bundle requires dbstore.service package to run, it doesn't care which bundle provides it it just needs an instance of this service to be able to work. So you can have multiple bundles providing implementations of the dbstore.service, and the domain-bundle can pick and choose at runtime what service to use.
It is really hard to explain OSGi concepts in just a several sentences, I'd really suggest you dig around the web on this and maybe even have a look at the OSGi specification.
Another way to explain it is to say that bundle/plug-in is a jar file with specific structure and metadata descriptors (MANIFEST.MF and plugin.xml), which describe its contents in Java language concepts - which java packages and services this specific jar contains and will expose to the OSGi runtime so that they can be consumed by other bundles. I.e. the bundle is the physical deployable entity while the descriptors are metadata about what actually is being deployed.
EDIT:
Package or Service-level dependencies also have some drawbacks, as Lii points out in the comments below, the main one being that it adds complexity and dynamics to the dependency model. Have a look at her or his comment below - it is worth reading!
You use Imported Packages when you want to use a specific package but do not care which plugin provides it. OSGI will choose one for you.
Eclipse plugins is something like extension to the IDE itself. But imported packages are actually packages that you'll use in your current project.
One is for development IDE another is for the project you are coding.
We are moving our application to the OSGI platform (All developers are using Eclipse) and are trying to figure out the best team environment for developing our bundles.
We have bundles from multiple sources:
Common bundles from projects such as Orbit or Apache that are managed by outside agencies.
Bundles that wrap domain specific jar files. We manage these bundles internally.
Bundles provided by other teams in the company that are effectively read only for us
Bundles provided by our team that contain actively developed source code.
In cases 1-3 we would like install in our local Eclipse IDE and provide a target platform. It seems to me we would just create a p2 repository that provides all of the bundles in 1-3 and provide them as a target definition. Feel free to point out a better solution if there is one.
The bundles contained in case 4 are stored in a Mercurial repository. Although the target definition looks like it can grab bundles from several sources it does not address how to include bundles from a (d)vcs.
What is the best practice? Do we put our (d)vcs bundle information in the target platform and just make developers download the correct bundles manually? Also how do we manage changes to the target definition? Do we have to email everyone when it changes, or is there a more elegant solution?
Thanks for your help.
space to share the target to the developer. The disadvantage is, that we have artifacts in our SVN!
But the p2 repository sounds much better. When every devloper activate auto-update, he will informed when updates avaiable.
I think we must try it in the future at my company.
Our actively developed source code we share by Team Project Sets (*.psf). This is an single text file which contains all repository information of the exportet eclipse projects. Try it in your Eclipse IDE with File -> Export -> Team -> Team Project Set. Are there any changes on the Project Set actually we send an email to our developers. An more elegant way I think is it to share it over the p2 repository.
I hope that helps and sorry for my bad english!
I am using eclipse, m2eclipse, maven-bundle-plugin, subversion, nexus and hudson, and it works like a charm, especially in a team environment.
Automating the manifest.mf generation is critical in OSGi, because doing this by hand is very error-prone. Use bnd for this (automated by bndtools or maven-bundle-plugin)
Pax Construct can help in building a complete OSGi runtime environment.
It's better to use Apache Maven [1] if you like to use Eclipse-independent environment.
Pros:
all your artifacts will be stored in one Maven repo. You can use such tools like Artifactory [2] to create and share Maven repo for whole team (to avoid any problems with 3rd-party artifacts)
there a lot of OSGi Maven tutorials available that help you to find answers to almost all your questions
Eclipse supports Maven very well with m2Eclipse [3] plugin
IDE is not so important in this case. Your team members can select any (even vi or emacs)
Cons:
you have to find Maven repos for all your artifacts. It's not so easy for Eclipse artifacts, but you can try to find them here: [4]
change your project structure based on Maven requirements
spend some time to understand and use Maven patterns (for OSGi)
[1] - http://maven.apache.org/
[2] - http://www.jfrog.org/products.php
[3] - http://m2eclipse.sonatype.org/
[4] - http://build.eclipse.org/helios/hybrid/final/
Regards,
Dmytro
Thanks to everyone who answered for the insight into how others are solving this problem.
We ended up going with Buckminster. It allows us to quickly describe where all our bundles are (cases 1-3 from p2 repositories, case 4 from mercurial) and provides one click setup of empty workspaces through the CQuery. It also integrates well with Hudson and simplifies CI setup compared to the PDE build I have used on other projects.