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.
Related
One of the most common uses of eclipse fragments is as a container for JUnit test classes. But how to write JUnit tests for Eclipse fragment when it plays another, more important role? For example, when it has platform specific code.
The problem is that it is impossible to create a fragment for a fragment. And you can't write tests for host plug-in to test the fragment because it doesn't even compile as a fragment is "merged" into a host only at runtime.
I don't know of a satisfactory solution, however, you may want to consider these workarounds.
Eclipse-ExtensibleAPI
You can use the Eclipse-ExtensibleAPI manifest header like this
Eclipse-ExtensibleAPI: true
It causes the packages exported by the fragment to be re-exported by the host bundle. Now you can create a test bundle that imports the desired packages and therefore has access to the public types in the fragment.
This isn't as close as test-fragments where you benefit from tests and production code using the same class loader that gives access to package-private types and methods. But you can at least test through the publicly accessible means.
Note, however, that this header is specific to Eclipse PDE and not part of the OSGi specification. Hence you are tied to this development environment. Furthermore, the packages of the fragment will be exported through its host bundle and will be visible not only for the test bundle but for all bundles.
Java Library
If your fragment has few dependencies and doesn't require the OSGi/Eclipse runtime you could consider treating it as a plain Java library w.r.t tests. Another sibling Java project could contain tests and have a project-dependency (Properties > Java Build Path > Projects) on the fragment project. Again, access to package-private members would not work.
And if you use a build tool like Maven/Tycho, some extra work would be required to declare dependencies and execute these tests during the build.
Bndtools
You could also look into Bndtools to see if this development tool fits your needs better than the Eclipse Plug-in Development Environment (PDE).
Plain JUnit tests are held in a separate source folder in the same project as the production code. This would give your test code access to the production code in the same way as if test-fragments were used.
Bndtools also supports executing integration tests, though I doubt that you would have access to the fragment code other than through services or other API provided by the fragment.
For CI-builds, Bndtools projects usually use Maven or Gradle with the help of the respective bnd(http://bnd.bndtools.org/) plug-in. Just as Maven/Tycho is used to build and package PDE projects.
Since Bndtools is an IDE extension to develop OSGi bundles, it doesn't know about Eclipse plug-in specificities such as extensions declared in the plugin.xml. Hence there is no builder and editor for these artifacts. But if you are lucky, you may even be able to use the PDE builder to show error markers for invalid extensions and extension points.
Another downside that comes with having production- and test-code in the same project, is that pure test dependencies like JUnit, mock libraries, etc. are also visible for the production code at development time.
Of course, the produced (fragment) bundles do neither contain test code nor test dependencies.
However, Bndtools itself is developed with Bndtools. So there is proof that Bndtools can be used to write Eclipse plug-ins.
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 two Eclipse projects: one that depends upon a certain library (android.jar) and one that is more abstract and doesn't contain that dependency.
I am in the process of migrating all classes that have no dependencies on the package, in my case android.*, to the more abstract project. Is there a Eclipse feature that can help automate the move?
Ideally, there would be feature that directly lets you automatically search for and move files that can be relocated to a new project. It would find files that that are:
independent of a specified package (with wildcards)
independent of other files within the same project that are dependent on the same package (in other words, no indirect dependencies on the package)
I submitted an Eclipse enhancement request to support such a refactoring. In the meantime, I found some promising tools to help with the decoupling and dependency analysis.
eDepend is a dependency viewer plugin that includes a
Class/Package dependency diagram that displays elements dependencies,
relationships with libraries/other projects and dependency cycles. It
can also list find classes that caused the dependencies.
STAN structure analysis for Java
nWire
Class Dependency Analyzer
Dependency Finder
Related questions: 1
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.