What is the big difference between launching Equinox via java -jar plugins/org.eclipse.osgi_3.6.0.v20100517.jar and using org.eclipse.equinox.launcher (basically, java -jar plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar)?
I suppose that org.eclipse.equinox.launcher provides some added value, but what exactly?
equinox.launcher processes special arguments before starting osgi framework. If you want to know more, the best way is reading the source code of equinox.launcher.
Well. The class which is used by both methods to start equinox framework is org.eclipse.core.runtime.adaptor.EclipseStarter. It's located in the org.eclipse.osgi_version.jar.
They use the same class. So, basically, they are the same.
However, the equinox.launcher provides more additional features. For example, a default splash banner, checking security and installation path, some more debug information etc.
The equinox.launcher is intended to be used as an application launcher of the framework/application.
If you directly run the org.eclipse.osgi_3.6.0.v20100517.jar file by invoking java -jar plugins/org.eclipse.osgi_3.6.0.v20100517.jar. It actually calls the main method in the EclipseStarter class.
This class is intended to be used as a programmable starter of the framework. That means you should use this class if you want to start the equinox framework from your code.
Generally speaking, you should use equinox.launcher for launching your OSGi application from command line or other similar means.
Hope this helps.
Related
There are a couple postings on this topic, but I can't get this to work with the latest version of Eclipse. I am using the JRE that comes with 2021-06, the one it puts in p2, x86_64_16.0.2.
I have tried various configurations of User Libraries, Maven dependencies, setting PATH_TO_FX, searching Eclipse Marketplace for JavaFX-as-a-plugin, e.g.,
How do I use JavaFX 11 in Eclipse? (2.5 years old)
https://www.javatpoint.com/javafx-with-eclipse
https://www.tutorialspoint.com/javafx-with-eclipse
https://gluonhq.com/products/javafx/
On a couple more elaborate examples, a couple builds had a scattering of missing methods, which I assume is due to JavaFX being somewhat in flux or instructions being quite outdated. I can get a simple Hello, World to build with javafx-sdk-17.0.1 as a User Library (what I'm doing now) and also some of the other configurations. When I try to launch Hello, World with various build-able configurations, I keep getting
Error: JavaFX runtime components are missing, and are required to run this application
Well, I was a bit too quick. I kept playing around, and adding quotes in the VM arg seems to work,
--module-path="C:\Program Files\Java\javafx-sdk-17.0.1\lib" --add-modules=javafx.controls
If the project is not a module project, the Used Library goes on the Classpath in the project properties, Libraries tab. If it is a module project, it goes on the Modulepath,and the following module-info.java file must be in the src with this minimal information:
module <myProject> {
requires javafx.controls;
exports <myPackageContainingFXAppClass>;
}
I just don't get it why people prefer to search half of the internet for tutorials instead of just consulting the official documentation first. Here it is: https://openjfx.io/openjfx-docs/#IDE-Eclipse It seems to be the best hidden secret that there actually is documentation for JavaFX that one could start with.
I just did the test. Googling for "javafx documentation" gives https://openjfx.io/ as the first search result.
I use --module-path=${PATH_TO_FX} --add-modules=javafx.controls.
Obviously PATH_TO_FX needs to be defined in Preferences->Run/Debug->String Substitution.
I have written some libraries which is in groovy.
My SOAP UI scripts which is currently used for API automation is using these libraries. As there is no debug option in SOAP UI Pro It is very hard to find the failures. Can someone help to debug the groovy script from eclipse. Which is called internally by a SOAP UI Script
Here is the way I get it done:
Instead of writing the logic in a groovy script using soapUI script editor, create groovy/java (user choice) class and its methods for the same logic. Here I assume that the script would have relative lots of lines code than fewer lines.
This has couple of advantages:
Intelli sense (which is not available if you write the same in soapUI tool)
Formatting of code
Easy debug
Maintenance of the code would be simple
Have a groovy/java project in the IDE of your choice (Intellij suits better for groovy projects, personal view only). Have the logic in the form of classes / methods. Compile those classes and create a jar file. Place it under SOAPUI_HOME/bin/ext directory.
Edit the soapui invoking script(SOAPUI_HOME/bin/soapui.sh on unix or .bat on windows) and add the debug parameters in JAVA_OPTS say
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=6006.
In the groovy script, just instantiate the above created class and call the appropriate method. Use arguments to your methods, that are available in groovy script context, log, testRunner etc variables. Even the script is done with fewer lines.
Debugging In Action:
In your IDE, configure remote debugging and add your debug points where it is needed. And start debug.
Now, just run the groovy script. Go to IDE, it should stop at the point where you added the debug point. You should be to do run through it normally like how you do with java projects in your IDE.
This works best for me.
EDIT:
Of course, this requires programming knowledge, know working in IDE (assuming that user knows as per the question) configuring build/class path etc.
Can't be done. SmartBear has been talking about this since at least 2007 (when SoapUI was still owned by Eviware), but still has not delivered. Here is one source: http://community.smartbear.com/t5/SoapUI-NG/Debugging-Groovy-scripts/td-p/33995
I have created a Java project application in eclipse and i am using the JRE System Library[JavaSE-1.7].
when i make an executable jar file of the application then test it on different computers which have different Java versions. The problem is that the jar file only works on some of the computers because of the java version.
my question is: is there away to make the application to check the computer see which java version it has and just use that version instead of the java version that was used to implement the project? in other words can you make an application which is not java version dependent?
any suggestion is of great help.
thanks
Thanks for all the suggestions and comments. But i think i'll just stick with the java 7 version and let the user know that they need java 7 to run it.
No, there's no way to check that, not in the way I think you mean.
In fact, on the one hand you have the Java version in which you compile the class (which you can choose), and on the other hand the Java version (of the JVM) in which your application runs (which you cannot choose).
Well, I do believe there's a way to check the Java version through some method call or similar, but I don't think it would help you here, I mean that I guess you can't do something like:
if(java-7) {
//do try-with-resources
} else {
// do usual try-statement
}
As #skiwi suggested, make sure your application compiles against an older Java version, and you should be fine with JVMs of that version and beyond.
I'm not sure what's causing your ClassNotFound error, but it could be that the JVM checks the required Java version needed and stops if it is above the available.
If you compile from the command line, there are switches to tell javac the source Java version and the target Java versions. I never had used them, so you better search for questions about them (i.e. javac source and target options). With those tools it will be the compiler that warns you against problems, without you having to explicitly check the version in your code.
There is a way to check the Java version, but you would need multiple executables to do it.
You would need a root executable, that would have a low-bar minimum Java version, simply so it can check the version of the systems, then it would launch an executable from there based on the system's Java version.
How you would come about this:
System.getProperty() allows you to, well, get system properties, along with a few other things, like versions of installed applications like Java.
You should create a separate JAR with one class:
public class Launcher {
public static void main(String[] args) {
String javaVersion = System.getProperty("java.version");
// Conditional to launch Jar file
if(correctVersion) { // if version is confirmed
Runtime.getRuntime().exec("java -jar whatever.jar");
}
}
}
The reason we need a root, lower bar executable, is because if the original executable can't run in the first place, how is it going to check the Java version?
Hope this works out for you. Sorry it took so long to get an answer.
I've got a Android AppEngine Connected Project I'm trying to build using GWT2.4 RequestFactory and Objectify on my Eclipse IDE.
Apparently I need to run the RequestFactory Validation Tool because I'm using ServiceName and ProxyForName annotations (these are required especially when working on the Android client side). My problem is the Eclipse can't validate it and the solution provided at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation#IDE_configuration is enough to make me rip my eyes out.
Since I'm working on a Windows machine, the shell script provided is not very useful. Trying to run Validation Tool from a cmd propt returns the error message:"This tool must be run with a JDK, not a JRE"
Can someone explain how this Tool is supposed to be run? Is there a way to use it as an External Tool in eclipse?
Normally if you follow carefully the instructions in the link you show, and run the GWT Development Mode from Eclipse, the Validation should be done automatically at the time you access the development URL with your browser.
For the record, I've actually had some problems with it, but launching the application several times maked it work.
Well, I ran into the same problem as well. When I tried annotation processing (under Java Compiler-> Annotation processing )was being disabled. So RequestFactoryDeobfuscatorBuilder was not being generated. Try enabling that and rebuilding your project.
I've just recovered from two days of hunting this bug down in a project that used to run validation properly but stopped.
In my case I had a new-ish generic BaseRequestContext and a specific sub-interface that extended it. My parent interface declared a method that didn't match the Locator's exactly (e.g. getThing(T) vs get(T)) and this wasn't reported as an error but did stop the validation tool from completing.
Apt is also removed in Java 8 : http://openjdk.java.net/jeps/117 . So beware.
Switching back to Java 7 will fix the issue if you are using Java 8.
I understood why the error happens sometimes in a project: the compiler was complaining it cannot find the directory .apt . But when I tried to create it manually it was not possible (under windows). I think the validation tool mutes the exception of not being able to create the directory: try renaming .apt in your validation tool calls (do a text search in your project)
I have an Eclipse plugin (A) which has a dependency on another plugin (B). Plugin B is simply a wrapper around a jar, which contains a native dll, and performs jni functionality.
Given this setup, I have the following code in A's Activator class's start method:
MessageConsole jniConsole = new MessageConsole("Opereffa Output", null);
ConsolePlugin.getDefault().getConsoleManager().addConsoles(new IConsole[] { jniConsole });
ConsolePlugin.getDefault().getConsoleManager().showConsoleView(jniConsole);
MessageConsoleStream stream = jniConsole.newMessageStream();
System.setOut(new PrintStream(stream));
System.setErr(new PrintStream(stream));
When plugin A performs its functionality, any use of System.out actually goes to the console within Eclipse. But native code used by JNI also writes to output stream, which I can't grab.
During development, output from JNI goes to the console of the Eclipse instance which has launched the running instance, which contains the plugins.
So how do I grab the JNI output and display in the console?
You could try using freopen to redirect stdout in exactly the same way as you do in Java, but on the native side. The question is whether this would work if you used it in your own plugin (with a new JNI dll): it may need to be used from within the dll doing the console output, I've no idea of the interaction between streams across DLLs. If stdout refers to a shared stream for the whole process, maybe it would work.
You can't, really. The native DLL uses stdio methods that you can't access from Java. If you write to System.out, the Java runtime eventually uses the same methods but for obvious reasons, changes the System.out have no effect to underlying the C runtime.
There is a hardware solution: Get a second monitor so you can see the terminal in which you started Eclipse all the time.
E.g. Eclipse 2019-06 regularly delegates std::printf(...) and std::cout from JNI code to the Console View
Flushing (=actually printed) is done by fflush(stdout);.