Does anyone know if there is a way to use JavaFX modules in eclipse workspace? I have an OSGi-maven multi-modular application.
Up until now, I have tried a couple of things.
To download JavaFX SDK and to add jars in eclipse as a user-defined library.
To bundle JavaFX jars and to use them as regular OSGi bundles after that (added as dependency and after that in target-platform).
Both of these things work. But, in the first case, every developer would have to manually add those jars as a library on the classpath. And in the second for every platform, we would have to have a different bundle for each module.
If I do neither of those things I have compile errors that JavaFX classes cannot be found (as expected).
Is there some third way to do this? By using some OSGi functionality or something like that?
I haven't found any way to add a module in MANIFEST.MF. Is that even possible?
I have added JavaFX modules as VM arguments in the OSGi framework launcher, and everything works fine. But I have to do one of those things mentioned before so that I don't have compile errors.
VM arguments: --module-path /path/to/javafx/sdk/11/lib --add-modules javafx.controls,javafx.graphics,javafx.base
I tried to convert an E4/OSGI/GEF/JavaFx project that uses JRE 8 to JRE 11 and OpenJFX 11, and found a way to do so.
In my case, I use SWT and javafx.embed.swt.FxCanvas. Including the user defined JavaFX library in the modulepath didn't work, generating class not found errors during compile-time; but including the library in classpath worked.
I also couldn't run the application using --module-path arguments; it gave NoClassDefFoundError exception for org.eclipse.swt.widgets.Canvas
My solution uses E(fx)clipse, which could also be the third option for you. After including the javafx libraries in the classpath, and including org.eclipse.fx.osgi in the project configuration, I used the following VM parameters to load JavaFX classes using E(fx)clipse.
-Dosgi.framework.extensions=org.eclipse.fx.osgi -Defxclipse.java-modules.dir=[openjfx-lib-directory]
You can also add -Defxclipse.osgi.hook.debug=true" to see debug messages from E(fx)clipse while loading the classes.
Related
As of Java 11 it is necessary to get JAXB from a separate library, not from the JDK. There are plenty of tutorials on the Web showing how to do that, but they all use Maven. The project I need to fix is an Eclipse RCP application. There does not seem to be an easy to make that work with Maven, as Maven essentially takes over most of what Eclipse would do but doesn't have RCP development capabilities.
Sooner or later Maven gets the required libraries. I would like to find another way to get and use whatever libraries are needed, just without using Maven. It should be possible. I just haven't found it.
Thanks.
I did what I wanted by downloading the needed JARs from https://mvnrepository.com/.
I'm trying to build an application that uses an embedded OrientDB (currently "memory:") graph database.
I'm using OrientDB 2.2
I am using Eclipse bndtools for my development environment.
I have added orientdb-core and orientdb-graphdb osgi bundles as build dependencies to my bundle, but on its own that isn't enough, I need access to the tinkerpop blueprint classes as well. There doesn't seem to be a tinkerpop blueprints osgi bundle that I can see.
I can include the blueprints-core jar as a build dependency, and that gets rid of the compile errors, but I then get into all sorts of issues trying to resolve the bundles so I can run something. (the primary error there that I don't seem to be able to get rid of is a complain about not being able to resolve "com.carrotsearch.hppc" -- I include that in my bundle, and export it, but still no joy there)
Shouldn't orientdb-graphdb either depend on a suitable bundle, or include and export the classes?
It sounds like you're running into the classic problem of wrapping a third-party, non-OSGi library as an OSGi bundle.
The best tutorial for this is on the EnRoute site. Note that you don't need to be using EnRoute for this tutorial to be relevant.
We have a Maven built Netbeans 7.1 rcp application that successfully mixes OSGi modules (packaging: bundle) and Netbeans modules (packaging: nbm) by wrapping the OSGi modules in Netbeans module wrappers. We want to migrate from using these wrappers to using the OSGi modules directly to simplify the build. There are around 30 wrapper, osgi module pairs and I would like to tackle the removal of the wrappers, one module pair at a time.
However when we replace a specific wrapper dependency with its osgi dependency in a modules pom that depends on it, and use the
<useOSGiDependencies>true</useOSGiDependencies>
in the nbm-maven-plugin configuration. Any other dependencies to other wrappers suddenly fail to build with transitive dependencies not available at runtime error.
Project uses classes from transitive module [xxx] which will not be accessible at runtime.
-- where [xxx] is the name of the OSGi module.
Of course I can fix the build by replacing the wrapper dependencies with the OSGi modules they were wrapping, but that escalates the size of the migration task considerably.
Once Ive got a build by "fixing" these transient dependencies the OSGi module that I picked to migrate appears successfully in a new cluster “extra”.
But at runtime the rcp fails to find the other osgi modules because, I guess, elsewhere in the build, they are still being referenced through wrappers.
Is there any way these wrappers and direct OSGi dependencies can co-exist? Or do I have to migrate all of the Netbeans wrappers to OSGi in one go?
Many thanks,
Phil Wilkinson.
Looks like theres no way to do this one wrapper at a time, its all-or-nothing with useOSGiDependencies. :(
You can change them to useOSGiDependencies=true one module at a time.
A detailed step-by-step guide would probably be too long for an answer, so here are some general rules for this to work:
Use nbm-maven-plugin version >= 3.11. Lower version has some bugs.
NBM wrapper's OpenIDE-Module & OpenIDE-Module-Specification-Version must match the wrapped bundle's Bundle-SymbolicName & Bundle-Version respectively.
If the bundle has package versioning, that has to be copied into the NBM wrapper's MANIFEST.MF as Netigso-Export-Package.
I'm using STS, and with a Web (WTP); Maven; Groovy stack.
By default, it appears that the Groovy classpath entries weren't marked to be exported, and I was issued with the following warning:
Classpath entry GROOVY_DSL_SUPPORT will not be exported or published.
Runtime ClassNotFoundExceptions may result. Classpath entry
GROOVY_SUPPORT will not be exported or published. Runtime
ClassNotFoundExceptions may result.
So, I added the libraries from Project Properties -> Deployment Assembly -> Add...
However, now I get the following error:
Invalid classpath publish/export dependency
/Users/martypitt/springsource/2.8.1.RELEASE/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE/lib/antlr-2.7.7.jar.
The project contains another dependency with the same archive name.
I worked around by excluding antlr manually from my pom.xml. However, this seems counter-intuitive, and leaves me concerned about issues later when I deploy to a server outside of STS.
Is there a more appropriate way to resolve this issue?
You do not need to export the DSL support container. It provides editing support for some built in Groovy AST transforms. There is nothing in the classpath container required for compilation or runtime.
Looks like your project is groovy project. Go to eclipse and install groovy addon - from software site - http://dist.springsource.org/snapshot/GRECLIPSE/e4.6/
After this restart eclipse and you should have these in path/eclipse to work with.
Detailed instructions # https://github.com/groovy/groovy-eclipse/wiki
Make sure you have the proxy configured properly - if any.
JDeveloper 10.1.3.x
I've recently learned that a library that is not exported will not be included on the classpath when deployed to the embedded OC4J container because it will have no library entry in the application-oc4j-app.xml file.
I have also demonstrated to myself that libraries that are not exported in projects that my project depends on are included in the application-oc4j-app.xml file.
Unexported libraries in my project do not get included. Unexported libraries in my project dependencies do get included.
Is that a bug or a feature, and can I change that behavior such that unexported libraries in my project dependencies also do not get included?
Thanks,
Steve
Unexported libraries should not get included in the application-oc4j-app.xml file. It looks like there is a bug, or some inexplicable behavior in JDeveloper.
IMHO, given a choice between Eclipse or <insert another IDE here>, and JDeveloper, it is wise to choose Eclipse.
One of the inexplicable behaviors that I referred to earlier, was the issue with JDeveloper compiling all projects in the application's directory, even if they were not part of the current workspace file (jws file). In other words, JDeveloper will consider a JPR file for inclusion in the workspace, even if the JWS file states otherwise (i.e. is does not appear visually in the JDeveloper workspace).
To date I have not found a way to specify different classpaths for build vs run time, but with help from a colleague, a solution to my specific situation was stumbled upon. Even though the connector is not a JDev project, the dependent project can reference the log4j jar file that is packaged and loaded with it. That effectively mimics the behavior at runtime, for both standalone as well as embedded oc4j container deployment, in which the web application and associated application code link to the log4j instance loaded by the 3rd party JCA connector's classloader. I did not think this would work assuming that a log4j library loaded by two different classloaders would still appear to be two distinct instances of the library with respect to log4j's static initializers. (That is what I am presuming motivates log4j to throw an exception if it finds another instance of itself in the classloader hierarchy.) Apparently this is not the case, at least for the embedded scenario. I do not have to test this for the standalone container since the Maven build knows not to include a copy of the log4j library jar in the application EAR file via the "provided" scope specification in the build file. The embedded OC4J container now loads the JCA connector, the associated log4 library instance, deploys the application, and allows both to use the log4j classes from the same log4j library file. Not entirely sure of how the connector and web applications classloaders interact, but it works now.