Quick re-install remotely the needed plugins when upgrading Eclipse - java

I moved from Indigo to Luna Eclipse. Indigo and Luna are located in different area, meaning most of the plugins which my tool uses does not exists in the new Eclipse.
So I get errors for places like:
import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.ui.plugin.AbstractUIPlugin;
import org.osgi.framework.BundleContext;
And also in the plugin.xml file:
<extension
id="application"
point="org.eclipse.core.runtime.applications">
<application>
<run
class="Application">
</run>
</application>
</extension>
<extension
point="org.eclipse.ui.perspectives">
<perspective
name="RCP Perspective"
class="Perspective"
id="MyFirstRCP.perspective">
</perspective>
</extension>
So I hope someone can answer the following questions:
Is there a quick way to re-download the needed plugins using the Eclipse (without third-party tools)?
If not, is it safe to just copy the needed plugins from the old directory to the new one?
The MAINFEST.MF file looks as follows:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: [TOOL_NAME]
Bundle-SymbolicName: com.[TOOL_NAME];singleton:=true
Bundle-Version: 3.6.4
Bundle-Activator: com.[TOOL_NAME].core.Activator
Require-Bundle: com.[PATH].util;bundle-version="1.0.0",
com.[TOOL_NAME].commons;bundle-version="1.0.0",
com.[TOOL_NAME].commons.testmanagement;bundle-version="1.0.0",
com.[TOOL_NAME].testlevel.ui;bundle-version="1.0.0",
com.[TOOL_NAME].report;bundle-version="1.0.0",
org.apache.commons.io;bundle-version="1.4.0",
org.eclipse.core.runtime,
org.eclipse.ui,
com.[TOOL_NAME].console;bundle-version="1.0.0",
com.[TOOL_NAME].scm;bundle-version="1.0.0",
com.[TOOL_NAME].preferences;bundle-version="1.0.0",
com.[TOOL_NAME].scm.testio;bundle-version="1.0.0",
com.[TOOL_NAME].disk;bundle-version="1.0.0",
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
I replaced the tool name and its path with [TOOL_NAME] so it will be more readable. I have problems with org.eclipse.core.runtime and org.eclipse.ui.

Eclipse Luna requires a minimum of Java 7 to run, it will not run on Java 6. This applies to RCPs built on this platform as well as Eclipse itself.
Your errors are because the Bundle-RequiredExecutionEnvironment levels for some of the core Eclipse plug-ins are not being meet.

Related

Eclipse RCP: Bundle-NativeCode in plugin fragment

Following this question.
I'm using Bundle-NativeCode header to specify native libraries that should be loaded by plugin.
It works fine when the libraries reside in the same plugin as the code that loads them (System.loadLibrary). However, when I try to put the libraries in a separate plugin fragment, System.loadLibrary fails with UnsatisfiedLinkError.
The manifest of the host plugin (when the libraries in the host plugin):
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Jni
Bundle-SymbolicName: com.ebar.workmode.jni
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.ebar.workmode.jni.Activator
Bundle-Vendor: EBAR
Require-Bundle: org.eclipse.core.runtime,
org.slf4j.api,
javax.inject;bundle-version="1.0.0",
com.ebar.workmode.contracts;bundle-version="1.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-ActivationPolicy: lazy
Export-Package: com.ebar.workmode.jni
Eclipse-ExtensibleAPI: true
Bundle-NativeCode: native/ipcs.dll ; native/ipcs_tcpip_plugin.dll ; osname=win32
The manifest of the plugin fragment:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: workmode JNI win x86
Bundle-SymbolicName: com.ebar.workmode.jni.windows.x32;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Vendor: EBAR
Fragment-Host: com.ebar.workmode.jni;bundle-version="1.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-NativeCode: native/ipcs_tcpip_plugin.dll ; native/ipcs.dll ; osname=win32
Activator.start of the host plugin:
#Override
public void start(BundleContext bundleContext) throws Exception {
System.loadLibrary("ipcs");
System.loadLibrary("ipcs_tcpip_plugin");
}
The error that I get when I remove the Bundle-NativeCode header from the host plugin:
java.lang.UnsatisfiedLinkError: no ipcs in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at com.ebar.workmode.jni.Activator.start(Activator.java:34)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
... 102 more
The plugin fragment is added to the product
The plugin fragment doesn't show any error in target platform state tab
The native folder of plugin fragment is included in binary build (in build.properties)
Why isn't it working and how to make the host plugin to load the native libraries from the plugin fragment? Or alternatively, is there a way to make the plugin fragment to load its libraries?

How can I call a method in jar from another eclipse plugin project?

I want to call a method in jar from another eclipse plugin project that has dependent to the project. But eclipse can't resolve the classname in jar.
Example:
I created com.plugin.main and com.plugin.sub project.
Added poi-ooxml-xxx.jar into com.plugin.sub project and added the buildpath through preference dialog.
Added all packages in jar as exported packages to MANIFEST.MF in com.plugin.sub project.
Added com.plugin.sub as required plugin to MANIFEST.MF in com.plugin.main project.
But eclipse can't resolve the classname in jar WorkbookFactory from com.plugin.main.actions.SampleAction. Why?
Information:
eclipse 3.6(Helios)
JavaSE-1.7.
WorkbookFactory's FQCN is org.apache.poi.ss.user.model.WorkbookFactory.
MANIFEST.MF in com.plugin.main:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Main
Bundle-SymbolicName: com.plugin.main; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.plugin.main.Activator
Bundle-Vendor: PLUGIN
Require-Bundle: com.plugin.sub;visibility:=reexport,
org.eclipse.ui,
org.eclipse.core.runtime
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-ActivationPolicy: lazy
MANIFEST.MF in com.plugin.sub:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Sub
Bundle-SymbolicName: com.plugin.sub
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.plugin.sub.Activator
Bundle-Vendor: PLUGIN
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-ActivationPolicy: lazy
Export-Package: org.apache.poi.ss.usermodel
Bundle-ClassPath: poi-ooxml-3.8-beta3-20110606.jar,
.
build.properties in com.plugin.sub:
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
.,\
poi-ooxml-3.8-beta3-20110606.jar
Try these:
Open the manifest files of both the project in Manifest Editor. Go to Runtime tab. In the Class path section check the entries. Add . (means current folder) if not exist. If . entry exists then move it on top. Save the editor and check.
Right click on com.plugin.main project and go to Properties. Go to Java Build Path. On right hand side go to Project tab. Then add com.plugin.sub project.
If adopted point 2 then remember test the application after exporting and running outside eclipse.
Wrong way of Add jars to project
You can add jars through Add JARs button in Library tab in Preference Dialog.
Then, .class file in the project is edited automatically as follows:
<classpath>
...
<classpathentry kind="lib" path="poi-ooxml-3.8-beta3-20110606.jar"/>
</classpath>
But the added tag should has exported attribute as follows:
<classpath>
...
<classpathentry exported="true" kind="lib" path="poi-ooxml-3.8-beta3-20110606.jar"/>
</classpath>
It isn't generated automatically. You have to add the tag in Order and Export tab by hand.
Correct way of Add jars to project
In eclipse, you shouldn't edit Java Build Path manually. You should use Plug-in Manifest Editor because .class is edited automatically when you edit a data through the editor. And also build.properties, plugin.xml, MANIFEST.MF will be edited correctly and automatically.
When you add jars to the project, you have to use Classpath section in Runtime tabs in Plug-in Manifest Editor. When add jars through the section, classpathentry tag with export attribute will be added in .class file. Not only that, the jar will be added as binary includes in build.properties.

Running OSGI bundle from OSGI command prompt :Import-package missing constraint

I have a bundle with the following mainfest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: HelloCamera
Bundle-SymbolicName: HelloCamera
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: hellocamera.Activator
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: cameraservice, cameraserviceimpl, org.osgi.framework
Layout:
HelloCamera
-> hellocamera
-> Activator.java
And a second bundle with this manifest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: CameraService
Bundle-SymbolicName: CameraService
Bundle-Version: 1.0.0.qualifier
Bundle-Localization: plugin
Export-Package: cameraservice, cameraserviceimpl
Import-Package: org.osgi.framework
Bundle-Activator: cameraserviceimpl.Activator
Layout:
CameraService
-> cameraservice
-> CameraService.java
-> cameraserviceimpl
-> Activator.java
-> CameraServiceImpl.java
I can run the first bundle from Eclipse and everything works fine as expected. I then exported both bundles as a CameraService.jar and HelloCamera.jar respectivly
I opened up my OSGI console, java -jar equinox.jar -console and
osgi> install file:CameraService.jar
osgi> install file:HelloCamera.jar
osgi> ss
id State Bundle
17 INSTALLED HelloCamera_1.0.0.qualifier
18 RESOLVED unknown_0.0.0 [18]
then I get
The Bundle could not be resolved. Reason: Missing Constraint: Import-Package: cameraservice; version="0.0.0"
After searching,
I found the problem was with the manifest files. When exporting the jars in my settings I said use the manifest file already in the folder.
I never looked at what the path was pointing to (assuming eclipse would set it correctly) however Eclipse hadn't changed its location so both jars were using the same Manifest file.
Lesson learned. Always check the form before blindly pressing finish.

Exception when trying to save images

When starting my Java application, I get exceptions when trying to save images. In Eclipse, however, everything works fine. The application is built using fatjar and the necessary libraries (jar_imageio.jar and ij.jar) have been selected for export as well.
I tried using ImageIO and ImageJ:
a.) ImageIO:
ImageIO.write(image, "jpg", new File(f));
Exception in thread "main" sun.misc.ServiceConfigurationError:
javax.imageio.spi.ImageWriterSpi:
Provider com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageWriterSpi
could not be instantiated: java.lang.IllegalArgumentException: vendorName == null!
at sun.misc.Service.fail(Unknown Source)
at sun.misc.Service.access$200(Unknown Source)
at sun.misc.Service$LazyIterator.next(Unknown Source)
at javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(Unknown Source)
at javax.imageio.spi.IIORegistry.<init>(Unknown Source)
at javax.imageio.spi.IIORegistry.getDefaultInstance(Unknown Source)
at javax.imageio.ImageIO.<clinit>(Unknown Source)
b.) ImageJ:
IJ.saveAs(image, "jpg", f);
java.lang.NoClassDefFoundError: Could not initialize class javax.imageio.ImageIO
at ij.plugin.JpegWriter.saveAsJpeg(JpegWriter.java:49)
at ij.plugin.JpegWriter.save(JpegWriter.java:28)
at ij.io.FileSaver.saveAsJpeg(FileSaver.java:340)
at ij.io.FileSaver.saveAsJpeg(FileSaver.java:332)
at ij.plugin.filter.Writer.run(Writer.java:24)
at ij.plugin.filter.PlugInFilterRunner.processOneImage(PlugInFilterRunner.java:256)
at ij.plugin.filter.PlugInFilterRunner.<init>(PlugInFilterRunner.java:105)
at ij.IJ.runPlugIn(IJ.java:158)
at ij.Executer.runCommand(Executer.java:127)
at ij.Executer.run(Executer.java:64)
at ij.IJ.run(IJ.java:249)
at ij.IJ.run(IJ.java:296)
at ij.IJ.saveAs(IJ.java:1579)
As #Victor says I think you should look at
Exception in thread "main" sun.misc.ServiceConfigurationError:
javax.imageio.spi.ImageWriterSpi:
Provider com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageWriterSpi
could not be instantiated: java.lang.IllegalArgumentException: vendorName == null!
I had this issue just yesterday and it was tricky. There are similar questions here. I found if I included jai_imageio in the jar and did not modify the manifest file to include the contents of the JAI manifest file or combine the files in the services folder of META-INF in your build then I had a number of errors similar to yours. My application did work though without JAI included since JAI was installed locally I opted to build it with JAI included for the time being.
Opening you jar you will find a directory called META-INF. In there is the file MANIFEST.MF. I use Maven to include the JAI things in the Manifest file so it looks like
Manifest-Version: 1.0
Implementation-Title: com.sun.media.imageio
Implementation-Version: 1.0_01
Built-By: myName
Specification-Vendor: Sun Microsystems, Inc.
Created-By: Apache Maven
Implementation-Vendor: Sun Microsystems, Inc.
Build-Jdk: 1.6.0_43
Specification-Title: Java Advanced Imaging Image I/O Tools
Specification-Version: 1.0-mr
Extension-Name: com.sun.media.imageio
Main-Class: myMain
Archiver-Version: Plexus Archiver
You should have your name and your main class substituted in there. You could just modify this file and jar it up yourself on the command line if you don't use Maven (or Ant) to get it working. I had the extra issue where some of my included jars were overwritting files in the services folder of META-INF. Instead I merged these files using Maven's Shade plugin.
add this lines into build.xml (solved for me)
<manifest>
<attribute name="Main-Class" value="${main.class}"/>
<attribute name="Built-By" value="${user.name}" />
<attribute name="Built-Date" value="${TODAY}" />
<attribute name="Implementation-Title" value="MyApp" />
<attribute name="Implementation-Vendor" value="MyCompany" />
<attribute name="Implementation-Version" value="${version.num}-b${build.number}"/>
</manifest>

is it possible to load jars-in-jars in JWS?

I have found MANY threads on packing all dependencies along with the project into one jar package, and it seems like there are many different ways to achieve this (oneJar, FatJar, Ant-build...)
So cooking up my own recipe, I have (after quite some effort) managed to package the project I am working on. In this one jar file, there is the code for the project plus all the jars that the project depends on which are loaded with jar-in-jar-loader that comes with eclipse. The resultant works fine on a number of different platforms, when it's ran through the terminal invoked via java -jar myjarfile.
Peachy, you might say, here's the problem though; when I sign my jar and try to run it via javaws (which is the ultimate goal here) I get an exception which I have decrypted to mean that libraries (in the case below org.apache.commons.lang.SystemUtils) are unaccessible.
So here's my question; is it not possible to load jars in jars when the applications is deployed for Java Web Start? If it is possible, what am I doing wrong? If not, what's the best alternative?
Thanks!
Below is the JNLP file along with the stackTrace I get when I run javaws myJNLPfile
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
codebase="file:///home/ukirik/workspace/myproject/dist"
href="project.jnlp">
<information>
<!-- Project info -->
</information>
<security>
<all-permissions />
</security>
<resources os="Mac\ OS\ X">
<j2se version="1.6+" java-vm-args="-XstartOnFirstThread"/>
</resources>
<resources>
<jar href="myjar-jws.jar" />
</resources>
<application-desc main-class="org.gvt.RuntimeMain"/>
</jnlp>
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1799)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1745)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1507)
at com.sun.javaws.Launcher.run(Launcher.java:129)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/lang/SystemUtils
at org.gvt.RuntimeMain.loadSwtJar(RuntimeMain.java:27)
at org.gvt.RuntimeMain.main(RuntimeMain.java:13)
... 9 more
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang.SystemUtils
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:332)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 11 more
If you are using the Eclipse jar-in-jar loader I think that you may need this in the jnlp file
<application-desc main-class="org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader"/>
That's assuming that your manifest is looking like this...
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 20.1-b02 (Sun Microsystems Inc.)
Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader
Rsrc-Main-Class: yourapp.mainclass
Rsrc-Class-Path: ./ swt.jar velocity-1.7-dep.jar
Class-Path: .
It seems like the problem is with the classloader.
You may want to use a custom classloader in JWS, as described here:
http://lopica.sourceforge.net/faq.html#customcl
Depending on exactly what you need to do, in terms of packaging, there are a couple of options.
The problem you're running into is that you're passing org.gvt.RuntimeMain as your main class for your jar in your JNPL file, but that's a one-jar jar. Because it's a one-jar jar, you need to provide class com.simontuffs.onejar.Boot instead, as
<application-desc main-class="com.simontuffs.onejar.Boot"/>
The reason for it, is that the one-jar plugin will generate that class, which will make use of a classloader that understands jars within jars, and then invoke your org.gvt.RuntimeMain class (it figures it out through looking at the manifests's One-Jar-Main-Class: header).

Categories

Resources