When creating a plugin, in the manifest file there's an option to "Activate this plug-in when one of its classes is loaded":
Also, when configuring a product, there's also option to specify plugin Start Levels:
Is the concept of "starting" the same or different than "activating". If they're different, how so?
Start Levels are used to control the order in which plug-ins are started when Eclipse itself is starting up. This is necessary to ensure that some services are available when they are needed. The picture below shows the default start levels. At level 1 org.eclipse.equinox.simpleconfigurator is the plug-in that loads most of the other plug-ins - so it needs to start first!
'Activate this plug-in when one of its classes is loaded' is an option to control when the plug-in Activator class is called (if it has one). If this is specified the activator is not called until something needs to use one of the other classes in the plug-in. If not specified the Activator will only be called if the plug-in is started by 'Auto-Start' in the start levels or an explicit OSGi start call.
Note that many plug-ins don't need an Activator at all.
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
As stated in the title: I want to run an Eclipse-Plugin, more specifically a GEF-Editor, without starting an Eclipse instance before.
I've tried to use the export functionality provided in the MANIFEST.MF file:
However, running the generated JAR (call it editor.jar) by executing java -jar editor.jar on the command line fails with the message no main manifest attribute, in plugins editor.jar.
I'm aware of the fact, that this is because my MANIFEST.MF file is missing the following line
Main-Class: <packagename>.<classname>
which defines an entry point for my application. However, I've no idea what exactly I need to do here (in the case of an Eclipse-Plugin), cause I don't have something like a main method. I assume Eclipse is running some magic code it doesn't show to me, when I start my project as an Eclipse Application.
So, what do I need to do?
You could try running a GEF editor as a Java application. See Draw2D examples to understand how it can be done. You could probably re-use your GraphicalViewer and PaletteViewer, which means that mouse based interactions with the diagram and palette will be preserved.
However, your editor class would probably have to be incorporated into an SWT shell. Also, all actions contributed to by your editor into Eclipse toolbars, popup menus etc. would be gone. Outline and Tree view would have to be incorporated into your java app somehow if needed.
Think you'd be better off with an RCP application.
Wrap your GEF editor in a simple RCP. You can create one via the Plug-in wizard, setting "Would you create a rich client application?" to "Yes" in the process. This gives you the option to create a minimal application via the Hello World template in the next step. Once you have this, you can either embed your GEF editor in this plugin, or declare a dependency from the new RCP application to your GEF editor plugin, and start the editor from the Application class' start method.
For an overview of resources about RCP development, cf. Getting started with the Eclipse RCP.
It really doesn't add that much overhead to your editor but gives you the opportunity to work with the platform's workbench and workspace metaphors and create easy-to-deploy-and-use application bundles.
Once you have that in place, you can test your RCP from plugin.xml > Overview > Testing > Launch an Eclipse application. This will not run a whole new instance of the IDE, but just the RCP application itself.
Rather than exporting from the MANIFEST.MF, look into creating a product (you can do it via the wizard: New > Product Configuration), and building it via the Maven Tycho plugin(s) (have a look at the respective - really worthwhile - tutorial from EclipseCon Europe 2012: http://eclipsecon.org/europe2012/sessions/building-eclipse-plugins-and-rcp-applications-tycho.html, this includes a section on creating a product as well). Tycho gives true cross-platform builds, as long as you're not on Windows.
No magic code there :).
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 develop plug-ins and a feature, and want to deliver a running application to our customer (so they don't have to get Eclipse on their own). Basically, I want to put my plug-ins in a minimal Eclipse instance (minus jdt, junit, and other plug-ins that we don't need).
I created a product configuration, but it wants me to specify a Product and Application in the Product Definition definition section (of the Product Configuration editor). How to I know what to specify for these? Choosing willy-nilly gives me the following error when I click the Launch an Eclipse application from the Product Configuration editor:
java.lang.RuntimeException: No application id has been found.
I've created products successfully from an RCP application before, but in this case I just want to deliver the bulk of Eclipse with our plug-ins installed. Am I doing this right?
Application could be headless or have GUI like RCP.
Product is an abstract definition for your product, it must depend on a specific application to be executed. You could refer to the built-in applications of eclipse itself.
I would like to write a simple Ant task that would interact with an Eclipse workspace to get some information from it. I would like to be able to use the various Eclipse API's (for example, IWorkspace).
My question is what would be the simplest way to go about doing this.
I have excellent knowledge of the Eclipse platform as a user of it - but none with development for Eclipse. I understand that, in runtime, my Ant task will have to be invoked under the same JRE as the workspace - that's a restriction I'm willing to be bound to.
I started by creating a Java project to hold my Ant task. I believe that the only thing in my way now is how to define the JAR dependency on Eclipse's JARs. I obviously don't want to depend on one specific Eclipse JAR as these are versioned (for example, Eclipse's "Resources" plugin). Is it possible to have my Java project buildtime-depend on "whatever the current JAR is for the Resources plugin"?
I think this article quite much addresses your problem: http://www.ibm.com/developerworks/rational/library/09/eclipsecustomanttasks/
It is targeted to the IBM Rational Application Developer, but that one is based on Eclipse and AFAIS there is not overly much non-eclipse-specific happening here, at least not regarding the specifics about how to make the task available in Eclipse (writing the plugin definition etc).
So, you want an Ant task that runs within Eclipse. And as you say, it's clear that those tasks are using the Eclipse API. As of this moment, I don't really understand how they're doing it. I've looked at the source of a couple of them and I still have questions.
To find the locations of all the Ant tasks contributed by Eclipse, do a Plug-in Search for org.eclipse.ant.core.antTasks. When I do that, I see twenty or so extensions, many of which define multiple tasks.
If you get the source bundle for a plugin that contributes one of these tasks, you can look at the source for it. RefreshLocalTask is in org.eclipse.core.resources; unfortunately, when I import this bundle into my workspace as a source project, the source for the Ant tasks doesn't get linked correctly. There is a separate jar (inside the bundle) for them, and, while the source is in the bundle, it's not clear how the jar is compiled. The upshot is that I don't have the Ant task source compiling in my workspace.
You can also Google for the Ant task source; here's the 3.6.0 source for RefreshLocalTask.
Anyway, in the source you can see calls to org.eclipse.core.resources.ResourcePlugin that are illustrative of what you probably need.
Ah, I see in the extension point description - right-click on one of those search results and choose "Show Description", or go there from the Manifest editor - that there is a flag you can set, "eclipseRuntime"; the text implies that if it is set, Eclipse will launch the task in the same VM.
You should probably say more about what you want to do, because there are several routes you can take.
Eclipse provides some Ant tasks that you can use in your build scripts. Here are a few. There are more, so search for "ant tasks" in the Eclipse docs; they're scattered throughout different pages. Eclipse Preferences (Window..Preferences, then select Ant/Runtime, and look at the "Contributed Entries" in the Classpath tab) shows you a list of Ant tasks that Eclipse contributes to the runtime whenever Ant is invoked from Eclipse; you can invoke any of these tasks yourself as long as you include the right jar.
It's possible to start up Eclipse from within an Ant task, because it's possible to start Eclipse from Java. You need to include the right jars and make the right calls; you also need to configure Eclipse correctly. "org.eclipse.core.runtime.adaptor.EclipseStarter" should give you some detail.
Perhaps you can use one or more of the variables Eclipse defines for use when launching Ant (or any other program). Try creating an External Tool Configuration (at the bottom of the Run menu) - select an Ant Build and try customizing it with arguments (from the Main tab) or environment variables (from the Environment) tab. Both give you access to Eclipse variables. But of course these are just values you can pass into your Ant script, not handles to anything you can invoke a method on.
What you can't do: I'm pretty sure that when Eclipse launches Ant, it is always in a separate VM, with no way to call back into Eclipse.
So perhaps you should say more about what you want to do.