I'm looking to understand osgi and find it confusing that every tutorial requires eclipse or is developed using eclipse (which complicates my understanding)
Is it possible to work with equinox without eclipse and is there an example of how this can be done?
You can create OSGi applications without eclipse. What you see in many tutorials is using the Eclipse Plugin Development Environment(PDE) for OSGi development. This is one way but not the only.
In many Apache projects like Apache Karaf you can see a very different maven based OSGi development. In this case you create normal maven projects and simply add a plugin to enhance the jar with the OSGi metadata. For simple bundles this is all you need.
As an example see the karaf examples and tutorials. In the case of karaf as a OSGi server you have the choice between equinox and felix for the OSGi framework.
A third approach is using bndtools. This again is a eclipse plugin and maven plugins but a completely different development workflow than PDE. The new examples for bndtools are also maven based like in Apache Karaf but they use a different assembly. As an example see this. It can be built with just maven but using the bndtools eclipse plugin makes it easier.
While Karaf uses features as primary assembly unit bndtools uses a OSGi repository + requirments.
So you have the choice of three different styles. Each with different pros and cons.
Especially the karaf style is also very applicable for intellij.
OSGi is a standard. Equinox is an implementation of this standard. As it is mentioned on Equinox homepage, equinox is even the reference implementation (http://www.eclipse.org/equinox/) :
The Equinox OSGi core framework implementation is used as the reference implementation and as such it implements all the required features of the latest OSGi core framework specification
As a consequence, yes it is possible to use other OSGi implementations : Apache Felix, ... (see https://en.wikipedia.org/wiki/OSGi_Specification_Implementations ). If you choose Felix, you will no longer use Equinox. But both implements the OSGi specification : https://osgi.org/javadoc/osgi.core/7.0.0/
In addition, you must distinguish the OSGi implementation from the development environment you choose (IDE). Eclipse is an ambiguous term that fits both. Even if you choose Felix implementation, you can code in eclipse.
I think that if most of the samples you find are based on eclipse Equinox and developed in Eclipse, it the result of the fact that :
- Equinox is the reference implementation of OSGi
- Eclipse IDE includes many tools to develop OSGi application through the PDE (Plugin Development Environment : https://www.eclipse.org/pde/ )
In conclusion, I would say that Eclipse probably cumulate the best IDE & implementation to work with OSGi. As far as I can see, it's a good thing for you to follow eclipse based tutorials, just remember that equinox is an OSGi implementation that you could replace by another like Felix.
Related
My ultimate goal is Invoking Eclipse plugin from Java. I see that an Eclipse plugin registers a class as Bundle-Activator in MANIFEST.MF. The start(BundleContext context) method will be called on this class. Where does this call come from?
Eclipse is made up of many repos that are mostly mirrored on GitHub. Some are deprecated and point to other repos. And it's a programming IDE and an OSGi framework at the same time? I find it hard to find the code for this core part of the framework that handles plugin loading. Where is it?
The project to interact with OSGi bundles is Eclipse Equinox. It is an implementation of the OSGi framework. You start equinox and load the bundle jar from there instead of putting them into the regular classpath.
Here you find some information how to do this in general:
http://njbartlett.github.io/2011/07/03/embedding-osgi.html
You can then interact with the bundles from you plain java application. This is not an easy thing though.
What makes things even more complex is that Eclipse is not plain OSGi. Eclipse predates OSGi and many of the concepts are still not fully adapted to plain OSGi.
So using eclipse plugins from a plain java application may be very hard.
I recommend to ask on the mailing list of the plugin you want to use if there is experience with using it outside eclipse.
I've been beating my head against a wall for about 6 months now and have not found a concise way of understanding the mechanism for developing an eclipse plugin with third-party resources.
We are attempting to develop an Eclipse ODA to ride on top of in-house Spring-based code that accesses a REST based info set.
In broad strokes - this is what I feel that we need to be able to do:
Augment our maven artifacts with Eclipse bundle information using tycho or a the felix bundle plugin.
Set up a plugin project through Eclipse for the ODA Implementation & UI.
Have Tycho generate the poms etc for the plugin.
Now here's where I get muddy. I understand that there are two approaches
Manifest-First - which is the standard mechanism for defining a plugin's dependencies
POM-First - which provides dependencies via Maven's resolution mechanisms.
I'm not entirely sure where to begin trying to start doing this as I've never worked on developing an eclipse plugin.
One of the other questions I have is, how does a developer of an eclipse plugin (maven aside) leverage already existing third-party code (i.e. Apache HttpClient 4.x)? Do they have to download the jars, dump them into a directory within the project, add to classpath, then go from there or is there a "repository" mechanism similar to what is used with ivy, maven, gradle?
Thanks in advance and I apologize if I was rambling a bit with that.
Disclaimer: Your question is very broad, so it is impossible to answer it completely. Still, I can give you some hints so that you know what to search for.
In the Eclipse universe, the primary source for libraries (in the sense of binary dependencies) are p2 repositories. However, since p2 repositories are rarely used outside of the Eclipse context, you won't e.g. find a p2 repository on the Apache HTTP Client project's download page.
To account for this problem, there is the Eclipse Orbit Project which provides libraries used by Eclipse projects in p2 repositories.
If you can't find the library or library version in the Eclipse Orbit, you may also be able to use the libraries from Maven repositories. This is for example supported by Tycho via the pomDependencies=consider mechanism.
Note however that Eclipse plug-ins can only depend on libraries which are OSGi bundles. So if the library in the Maven repository is not yet an OSGi bundle, you need to convert it to an OSGi bundle first, e.g. with the maven-bundle-plugin and the Embed-Dependency mechanism.
The best way for an Eclipse plugin to consume libraries is as OSGi bundles. You just install those bundles into your target platform and reference them in the same way as eclipse.org plugins. Some of the library providers already offer their libraries as OSGi bundles. Absent that, you can typically turn a plain library jar into an OSGi bundle simply by adding a few manifest entries.
Depending on the build system you use and whether the libraries you need are available as OSGi bundles packaged into an online p2 repository, you can reference the URL and rely on your build to download and install the bundle.
If question of choosing a build system for Eclipse plugins with dependencies is still relevant:
Today I released new gradle plugin: Wuff version 0.0.1, which (I think) completely solves the problem. It allows to build Eclipse bundles and applications as they would be "normal" Gradle projects. All OSGi woodoo is auto-generated (although customizable). All dependencies are usual maven dependencies - regardless of whether dependency is OSGi or "normal" library.
Sources and doc: https://github.com/akhikhl/wuff
The base of our enterprise application is OSGI and we have several Java projects that are logically OSGI bundles. We use Maven to compile the application using the Maven Bundle plugin. But this process is time consuming and makes it impossible to debug the application. We also use the Runner and Pax(:provison) plugins to run the application. If we could rely on the Auto build function of Eclipse and also debug the application it would make our lives so much easier. Is there a way to configure Eclipse to be able to compile (and may be run) an OSGI-based application?
I'm not entirely sure if I understand you, but here goes.
Well, running/debugging OSGi applications in Eclipse is really easy, as long as your bundles reside in PDE aware projects or at least are on your target platform.
Do you have the source of all your bundles? Debugging without source isn't all that useful. If you do, can you just import all the source of your bundles into your Eclipse workspace?
Otherwise you can create a target platform, add all your bundles to that. (as a first attempt, I'd say dump all your bundles in a directory and point the target platform there)
Either way, then you should be able to Run (or debug)-> OSGi framework -> New -> Pick your bundles -> Start
You can both pick bundles from or target platform and from your workspace.
For building, you can use Eclipse Plugin Development Environment (PDE). Despite its name, it isn't specific to building Eclipse plugins and can be used for working on pure OSGi bundles. Eclipse plugins are OSGi bundles with some extras.
Cannot help you with the running or debugging part, although I do know that some enterprise-oriented OSGi platforms provide extensions to PDE.
If you're already using the maven bundle plugin, you may find that PDE's manifest-first approach isn't a good fit with your existing code-first build (I assume at the end you want both an IDE build for development and debugging, and a command-line build for continuous integration and automated testing).
You have two choices. As others have suggested, you can use Eclipse's integrated PDE, and use Tycho for your maven build. Tycho uses the same data used by PDE, so you don't have to write things down more than once. Alternatively, you can stick with the maven bundle plugin and use bndtools within Eclipse. Like the bundle plugin, bndtools is code-first, so you won't need to worry about maintaining manifests. However, you may find there isn't quite as big a set of features in bndtools as in PDE, and I'd suggest still checking your manifests by hand to make sure you understand what's being generated. Whether you prefer manifest-first or code-first is a bit of a heated philosophical debate.
Look at bndtools. bndtools is using the same bnd that is underlying the maven bundle plugin. You can even use bndtools together with m2e. bndtools is available from the Eclipse market place.
I made quite a few easy OSGi test projects in Eclipse RCP. My typical workflow would always be:
Make 3 different projects: APIproject, Clientproject and Serverproject
Edit the MANIFEST.MF of APIproject to export the api package
Edit the MANIFEST.MF file of Clientproject and Serverproject to add the required API package
Choose "Run as..." > "Plugin Framework"
OSGi console starts in eclipse and everything seems to work
I also tried wiring things by using Declarative Services, which worked well like this too.
Now recently I wanted to try out iPOJO. The problem is that I get the feeling that I've been doing my OSGi development the wrong way.
Can it be that I should instead make 1 project en make it work like no OSGi is involved. And then afterwards, just export each package to its own bundle by means of (for instance) the BNDL tool? Should development be done in a normal Eclipse (java, not RCP) or any other java IDE for that matter?
So that's why I have these questions:
What IDE setup is normally used to develop OSGi with iPOJO?
And what is the normal workflow to be used when developing OSGi projects (maybe with iPOJO)?
Normally when I develop OSGi bundles (not Eclipse RCP bundles) I use the following tools:
Maven 2 as the build system.
Apache Felix maven-bundle-plugin to generate MANIFEST.MF automatically.
Pax Exam to create integration tests that run inside an OSGi container.
Pax Runner to execute my bundles in any OSGi framework (equinox, felix, etc.).
IntelliJ (or sometimes Eclipse) as a standard IDE without any OSGi extras.
I have not yet developed any Eclipse RPC bundles, but there's a new tool for Maven 6 Eclipse RPC build integration called Tycho (http://tycho.sonatype.org).
I was trying to start new swing application using maven,
so I started searching on maven documentation but (frustratingly) found no clue. So I'm asking:
what is the archetype used?
what are the dependencies?
how to build swing app in maven [is there is plugin to do so]?
what is the archetype used?
A swing application is a standard JAR so just use the standard archetype:
mvn archetype:generate -DgroupId=com.mycompany.app \
-DartifactId=myswingapp \
-Dversion=1.0-SNAPSHOT
what are the dependencies?
If you plan to use the standard Swing API only, there aren't no extra dependencies to declare. But if you want to use things like JGoodies, MiGLayout, SwingX, Flamingo, SwingFX etc then you'll have to add the appropriate artifacts and repositories. But there is no universal answer to your question.
how to build swing app in maven [is there is plugin to do so ]?
A Swing app is not really particular. I would maybe just consider using Java Web Start (and the Maven Webstart plugin) or maybe a cross platform installer like IzPack (and the Maven IzPack Plugin). But you have time for that, you need an application before :)
Basically, if you are only using Swing (I mean if you do not want additional features such as SwingX for example), then you will not need to add specific information in your pom.xml file, as everything needed for Swing development is already embedded in the JDK.
Concerning the build process, there is also nothing specific additions here. However, you may need be interesed in:
Creating an executable JAR.
Making a big JAR, that also contains all the dependencies.
Check these links if you have problems finding documentation about maven Better builds with Maven and Maven: The Definitive Guide. Then you will figure out that you can build any kind of app like swing using maven. Maven is not a framework is project management and comprehension tool.
Note: Maven: The Definitive Guide was split into two books. The link goes to the blog post that links to both of them.