I installed Bndtools in Eclipse and tried out their quick tutorial: http://bndtools.org/tutorial.html
But as soon as I want to start a very simple component via the "Run OSGi" button, I receive a Launch Error prompt:
Status ERROR: bndtools.core code=0 At least one of the required parameters could not be detected; specify an override. Detected: osgi.native;osgi.native.osname:List<String>="null";osgi.native.osversion:Version=null;osgi.native.processor:List<String>="x86-64,amd64,em64t,x86_64", for cmd: native_capability, arguments; [native_capability] null
Status WARNING: bndtools.core code=0 No translation found for macro: native_capability, in org.example.impls null
The Apache Felix Gogo Shell starts at some configuration with the OSGi Framework Run setting, but the errors persist. I tried it with Eclipse Kepler and Lunar, as well as JDK 7 and 8.
I have no idea what to make of the error and warning. Something seems to be missing somewhere. Does anyone know how to solve this issue?
Thanks in advance!
For completeness sake; this error is caused by a bug in bnd (reported here: https://github.com/bndtools/bnd/issues/573). The operating system name/version reported by Java is not recognised, as this version of bnd was released before Windows 8.1.
Aside from the error in the output there should be very little effect. You may encounter problems running bundles that contain native code, but the majority of bundles containing pure Java will work fine.
I have not seen this error before. Did you select an OSGi framework and Execution Env. in the run configuration?
Please see if your bnd file contains launch descriptions. Usually, the launch descriptions are defined in a different file called .bndrun file. (A bnd.bnd file can actually also act as a .bndrun file.) The bndrun file inherits properties from the workspace, not the profile.
In such scenarios - you will have to click the run button from the .bndrun file
Related
I tried to make a headless Eclipse RCP because I want to launch it through a C file with JNI. I created a plug-in project, set the correct settings in MANIFEST.MF and created Headless.product. Everything works, also Application.java, but when I tried to export the .product to have the executable file, it gave me an error. So I tried with an existing project from this tutorial (just in case the problem wasn't in the settings) and it gave me the same error:
Cannot complete the install because one or more required items could not be found.
Software being installed: Headless Example 0.0.0
(com.codeandme.headless.headless 0.0.0)
Missing requirement for filter properties ~= $0: Headless Example
0.0.0 (com.codeandme.headless.headless 0.0.0) requires
'com.codeandme.headless.headless_root.gtk.linux.x86_64 [1.0.0]' but
it could not be found
This is the screenshot of the problem
(Where com.codeandme.headless is the name of the project)
Now, what should I do to make the export possible? Anything to do with org.eclipse.equinox.executable? And if yes, where and how can I add it?
Thank you in advance for your help :)
I had the same error message:
Missing requirement for filter properties ~= $0: Application 0.0.0 (org.acme.project.application 0.0.0) requires 'org.acme.project.other 1.2.3' but it could not be found
For some reason this error (also) means, that org.acme.project.other is present... twice.
So in your case, open the "Content" tab of the "Target Editor" and make sure that com.codeandme.headless.headless_root.gtk.linux.x86_64 is not present in two distinct versions. This bundle might be inside a feature, so it might be a bit hard to find where the second version came from.
I recently upgraded to IntelliJ 14, then added Scala support.
My main files stopped running. For example the GUI file, which has no errors and is a totally self contained hello world style for testing this error:
Exception in thread "main" java.lang.ClassNotFoundException: GUI
It makes no sense and I'm pretty frustrated that the IntelliJ devs are slacking in not auto-detecting a solution to this. I have tried everything to fix it. From settings, compilers, to making the project from scratch.
I only had a bit of luck when making it from scratch, but as soon as I started to add my other files (files that were not even being used!) it starts with the error.
It seems that any files outside of the original project module (when creating a new project to test fix) will not run giving ClassNotFoundException.
This may be related to my other question: https://stackoverflow.com/questions/27516673/cannot-run-file-located-out-of-main-module-intellij-14-java-scala
Sample View of the problem
I had the same problem and was able to fix it by right clicking the directory my class was in, and clicking Mark as sources root. This should make your class discoverable and able to run.
Solution
Turns out that Make, No Error Check does not work the same for scala as it does for Java.
Errors in the scala files will cause an ambiguous error message on run, with no clear link to the error.
Fixing the scala files fixes the error.
In my case, the solution was at the JDK and java level.
When I set JDK 14 this error occurred.
So when I work with a scala project, I set java 8 everywhere in the project(module) settings and in the configuration of the main method.
In project(module) settings section: Project, Modules, SDK's
In main method settings: JRE
I have JDK8 installed in the directory C:\Program Files\Java\jdk1.8.0_05\ and I have my PATH Environment Variable set to C:\Program Files\Java\jdk1.8.0_05\bin.
Now; in order to use Amazon's Product API I follow their guidelines here under the Java getting set up section; and I use the following command...
wsimport -d ./build -s ./src -p com.ECS.client.jax http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl -b jaxws-custom.xml
after opening a command prompt in a custom directory I created on my desktop; that custom directory contains the build and src directories as specified in the instructional page provided by Amazon.
Now when I run the command aforementioned; I receive the error...
'wsimport' is not recognized as an internal or external command
however; if I run Java -version within the same command prompt all works well and as expected.
Not sure where to go from here or why it isn't reading through?
Note I already attempted the solutions at this page; to no avail.
I found this in the comments section of the following article. I include it here in full because I think it explains why your JDK8/wsimport fails to build and consequently why it works when you switch back to Java7.
http://blog.takipi.com/6-reasons-not-to-switch-to-java-8-just-yet/
Even though the article was written over 3 years ago, I am still having java8/wsimport problems (2017).
Why not mention some more obvious ones:
The new defaults in Javadoc (called doclint) will break your build. In particular if you are using Maven and some kind of CI (e.g. Hudson,
Jenkins) you'll quickly realize that you can't just take your project
and build in JDK8. Your build will almost certainly error out because
of the new Javadoc. (I have yet to see a project that didn't). The
reason is that in Maven a return error code from the javadoc tool will
stop the whole release process ... and as I said I have yet to see a
project that would not somewhere have a Javadoc doclint noncompliance.
Most larger projects (e.g. Netty) seem to solve the problem by simply
turning off doclint (which of course wasn't the idea behind doclint)
or they stay on JDK7 for a while longer until they iron out all their
comments problems.
Code generation tools in JDK8 (e.g. wsimport) produce code that is not doclint compliant. This is a clear bug and well documented. It
means that one part of the JDK8 is not working with another part of
the JDK8. Expect to have to circumvent this somehow if you have a web
consumer application.
I had an issue where I was getting the following error in the Problems view when attempting to save/compile a Java script library in a DB held on a server. I'm using DDE 8.5.3 (Note, I've changed the app and the lib names):
Project 'app_name.nsf.java-lib-name.javalib' is missing required library: 'C:\lotus\notes8\jvm\lib\axis\axis.jar'
It's worth noting that I'm using the Eclipse based Java editor, this issue doesn't happen if I use the traditional editor.
My script library had a number of JAR files associated, however none of them were included via the path which appeared to be causing the issue. Also it couldn't have been some deeply concealed dependency thing as all of the included JARs are custom built and none of them user or require Axis.
I also did a test creating a fresh library without pulling any external JARs in and the same error occurred.
It turns out the problem was being caused by the use of "JavaUserClassesExt" in my local notes.ini. I've recently been using a LN client app which depends on Axis and part of the install process includes dropping the relevant Axis files into a custom directory within jvm/lib/ext and then updating the ini to include those files using "JavaUserClassesExt" when launching the JVM.
I guess the issue has only shown up now because I've recently had to change the location of my LN install from the path indicated above (lotus\notes8) to something slightly different (lotus\notes853). I copied my ini across from the original install location which is why it still references the old path. Once I removed the references to the wrong path, the error cleared up.
So I can kind of understand what is happening, the JVM is attempting to load all required files on the classpath but is running into an issue because the files being requested via "JavaUserClassesExt" can no longer be found.
What I don't understand is why it's throwing this error when I'm attempting to edit a script library in a completely different database which has nothing to do with the Axis framework. I'd expect a compile error if trying to import anything to do with Axis based on it being on my local classpath, but to throw this error when the library has nothing to do with Axis seems confusing and incorrect to me.
As I mentioned, this only happens when using the Eclipse based Java editor so I presume this is a bug with that version of the editor.
Has anyone come across anything similar? Would this be classed as expected behaviour or can anyone confirm if this is a bug?
I realise this is a pretty edge case issue but would be interested in any insight.
Cheers,
Lee
Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?
After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.
It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.