NoClassDefFoundError: Unable to run Tycho-built Eclipse RCP application under Linux/Mac OS - cross-platform

I'm developing a cross-platform RCP application in Win 7 (64bit), Indigo/Java 1.6, building the product with Tycho.
While the application runs fine from the Run Configuration within eclipse, and the Win x_86_64 build runs fine as well, I get the following errors on both xubuntu (with OpenJDK Java 6 Runtime (1.6.0_24) and Mac OS X (1.6.0_35).
The error (on Linux) looks like this (running java myprogram):
Exception in thread "main" java.lang.NoClassDefFoundError: myprogram
Caused by: java.lang.ClassNotFoundException: myprogram
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: myprogram. Program will exit.
I'm sure I've come across this before, and I think it was something stupid (this has happened on Windows before AFAIK, and re-installing Java fixed it for some reason). In this case, however, I think it must be to do with the build/target platform/Tycho setup.
The part of my parent POM responsible for the cross-platform build looks unsuspicious enough:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<resolver>p2</resolver>
<pomDependencies>consider</pomDependencies>
<!-- configure the p2 target environments for multi-platform build -->
<environments>
<environment>
<os>linux</os>
<ws>gtk</ws>
<arch>x86</arch>
</environment>
<environment>
<os>linux</os>
<ws>gtk</ws>
<arch>x86_64</arch>
</environment>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86</arch>
</environment>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
<environment>
<os>macosx</os>
<ws>cocoa</ws>
<arch>x86_64</arch>
</environment>
</environments>
</configuration>
</plugin>
Does anybody have any ideas why this might not work?
Many thanks!

This is not how you run an Eclipse RCP application.
You either need to launch it with the appropriate native launcher, or with a java -jar plugins/org.eclipse.equinox.launcher_(yourVersion).jar (see this documentation) and probably further arguments to select your application.
Also, you need to make sure that you have the bundles in your application that Equinox needs to start up. You can do this by including the feature org.eclipse.rcp in you product.

Related

Eclipse 2018-12 has dependency to Windows, Linux and MaxOS

I just updated my application's org.eclipse.e4.rcp feature from Eclipse 4.9. to 4.10 (or 2012-09 to 2012-12). Now I get the exception:
[ERROR] Cannot resolve target definition:
[ERROR] Problems resolving provisioning plan.:
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.cocoa.macosx.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.ppc64le [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
Both the .target file and the pom.xml have defined the target platform as being for Windows only:
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
And the target file has additionally includeAllPlatforms="false". If I set it to true, I get the very similar exception:
[ERROR] Software being installed: org.acme.plugin 7.0.0.qualifier
[ERROR] Missing requirement: org.eclipse.swt 3.109.0.v20181204-1801 requires 'org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801]' but it could not be found
[ERROR] Cannot satisfy dependency: org.acme.plugin 7.0.0.qualifier depends on: java.package; org.eclipse.jface.preference 0.0.0
[ERROR] Cannot satisfy dependency: org.eclipse.jface 3.15.0.v20181123-1505 depends on: osgi.bundle; org.eclipse.swt [3.104.0,4.0.0)
If I add the fragments to the target platform, I get the following message (which is completely understandable):
org.eclipse.swt.gtk.linux.x86_64 3.109.0.v20181204-1801 cannot be installed in this environment because its filter is not applicable. -> [Help 1]
Setting the target platform to planner mode doesn't work. Neither does setting <org.eclipse.swt.buildtime>true</org.eclipse.swt.buildtime> in the pom.xml (false doesn't work either).
Looking at the XML file of the feature I can't see anything wrong with it (the fragments are defined for their OS only), still the target platform wants to haven the fragments for Linux and MacOS, even though I'm on Windows.
The target platform looks like this (yet again, it works if I replace 2018-12 with 2018-09):
<location includeMode="slicer" includeAllPlatforms="false" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
<repository location="https://download.eclipse.org/releases/2018-12/"/>
<unit id="org.eclipse.e4.rcp.feature.group" version="0.0.0" />
<unit id="org.eclipse.emf.common.feature.group" version="0.0.0" />
<unit id="org.eclipse.emf.ecore.feature.group" version="0.0.0" />
<unit id="org.eclipse.equinox.executable.feature.group" version="0.0.0" />
<unit id="org.eclipse.rcp.feature.group" version="0.0.0" />
</location>
And it's hooked in the pom.xml like this:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<resolver>p2</resolver>
<target>
<artifact>
<groupId>groupId</groupId>
<artifactId>org.acme.plugin.build</artifactId>
<version>7.0.0-SNAPSHOT</version>
<classifier>platform</classifier>
</artifact>
</target>
<ignoreTychoRepositories>true</ignoreTychoRepositories>
<environments>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
</environments>
</configuration>
</plugin>
What is the problem? How can I fix it?
Who would have thought? It's the exact same Eclipse bug as in this question again. For some reason our build process gives preference to the plug-ins in Maven Central over the ones in the Eclipse repository. Since they have broken Maven dependencies, and since Tycho (obviously) still evaluates these dependencies, that breaks the build.
In our case the fix was as easy as moving Maven Central down below the Eclipse repo in our target platform.

Arquillian and Open Liberty requires existing installation?

I'm familiar with Tomcat/TomEE and testing applications using Arquillian. Now were are switching to Open Liberty. I see there is a module for Arquillian using embedded Open Liberty but it seems to require an existing Open Liberty installation whose path is provided in the configuration. This makes it non-portable and therefore unsuitable for automated testing since the installation has to be present at the exact same path. Arquillian and TomEE are self-contained, no installation required. Therefore my question is why this isn't also possible with Open Liberty? And is this planned for the future?
For reference this is how you use Arquillian with TomEE/Tomcat:
<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://jboss.org/schema/arquillian"
xsi:schemaLocation="http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd">
<container qualifier="tomee" default="true">
<configuration>
<property name="httpPort">-1</property>
<property name="stopPort">-1</property>
<property name="users">user=pass</property>
</configuration>
</container>
</arquillian>
As you can see, there is no path to a local installation required to run the tests. The only thing you need to do is a add a couple of Maven dependencies in test scope that pull in TomEE (embedded). If the same would work for Open Liberty that would be great.
Going further..so the above is how we do automated testing
but it still uses the location.
I see, regarding not needing any location specified at all, you say:
"The only thing you need to do is a add a couple of Maven dependencies in test scope that pull in TomEE (embedded). If the same would work for Open Liberty that would be great."
So, thinking, maven will put a bunch of classes on the classpath due to the TomEE
dependancies and then the test run will find the appropriate container to
run the tests on.
I will raise an issue over on
https://github.com/OpenLiberty/liberty-arquillian/issues/39
to cover the requirement please feel free to add remarks etc.
If you have a look at https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.microprofile.config.1.2_fat_tck/publish/tckRunner/tck/src/test/resources/arquillian.xml
you will see an example arquillian.xml that sets $wlpHome
<property name="wlpHome">${wlp}</property>
from an environment variable $wlp.
('wlp' is short for Websphere Liberty Profile)
The wlpHome variable is used in the managed/local container here:
https://github.com/OpenLiberty/liberty-arquillian/blob/42cb523b8ae6596a00f2e1793e460a910d863625/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L224
An example that does this dynamically is the setting of the
system property ${wlp} here:
https://github.com/OpenLiberty/open-liberty/blob/95c266d4d6aa57cf32b589e7c9d8b39888176e91/dev/fattest.simplicity/src/componenttest/topology/utils/MvnUtils.java#L161
If you have any more queries please post them...
and hope you love OpenLiberty - it rocks!
Gordon
The result you seem to be trying to achieve is a embedded runtime for liberty using arquillian. However, all as far as I can see, the openliberty team only provides a remote container adapter and a managed container adapter at the moment.
With us having a similar need, wanting to run automated integration tests where we wouldnt necessarily have a Openliberty server in-place. We managed to work-around this using liberty-maven-plugin.
The build/testing process would then be:
Running mvn verify, liberty-maven-plugin would generate the specified openliberty which we want to run our tests against.
<plugin>
<groupId>net.wasdev.wlp.maven.plugins</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>${version.liberty-maven-plugin}</version> <!-- plugin version -->
<configuration>
<assemblyArtifact> <!-- Liberty server to run test against -->
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>18.0.0.4</version>
<type>zip</type>
</assemblyArtifact>
<configDirectory>src/liberty/${env}/</configDirectory>
<configFile>src/liberty/server.xml</configFile>
<serverName>defaultServer</serverName>
</configuration>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>create-server</goal>
</goals>
</execution>
</executions>
</plugin>
As liberty-maven-plugin per default adds the Liberty server to the target/folder
<arquillian xmlns="http://jboss.org/schema/arquillian">
<container qualifier="liberty-managed" default="true">
<configuration>
<property name="wlpHome">target/liberty/wlp</property>
<property name="serverName">defaultServer</property>
</configuration>
</container>
</arquillian>
This way we can assure that a runnable liberty server according to our liking is always existant in our local environment or e.g. our Jenkins CI/CD Server, essentially getting the same effect as having a embedded container.

Unable to deploy Mule app on mule standalone server

While using the Mule Maven plug-in to deploy the deployable archive on the Mule standalone server I receive this error intermittently.
Error : Caused by: org.apache.maven.plugin.MojoExecutionException:
Could not rename C:\mule-standalone\mule-ee-distribution-standalone-3.4.0\mule-enterprise-standalone-3.4.0\apps\**MyProject.zip**.temp
to C:\mule-standalone\mule-ee-distribution-standalone-3.4.0\mule-enterprise-standalone-3.4.0\apps\**MyProject.zip**
I am using the following Maven plug-in:
<plugin>
<groupId>org.mule.tools</groupId>
<artifactId>maven-mule-plugin</artifactId>
<version>1.9</version>
<extensions>true</extensions>
<configuration>
<copyToAppsDirectory>true</copyToAppsDirectory>
</configuration>
</plugin>
This happens when you have a file opened in the mule apps folder. The maven-mule plugin is not able to rename /delete the older app and as a result the build fails.

Problems running Java 8 TestNG inside IntelliJ

I am writing a Maven application using OpenJDK 1.8 and running tests using TestNG.
When I run Maven from the command line everything works fine, but when I try to run the test inside IntelliJ, then the make process is displaying the following error:
java: javacTask: source release 8 requires target release 1.8
I have the project settings pointing to the 1.8 JDK and Project Language Level 8.
Inside Maven I have the following block (which I am guessing is not getting called yet as it seems to be the make causing the problem)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
I have even configured the Maven Runner JRE to point to the 1.8 JDK.
I just don't seem to be able to get IntelliJ 12.0.4 to run the tests properly
Am I missing something?
After the hint from CrazyCoder it turns out that .idea/compiler.xml had the following section in it
<bytecodeTargetLevel>
<module name="game" target="1.7" />
</bytecodeTargetLevel>
I changed this to:
<bytecodeTargetLevel>
<module name="game" target="1.8" />
</bytecodeTargetLevel>
and it worked
There is another way to make it. Go to Files->Other Settings->Type "javac" in the search bar -> change the JDK default to "1.8" or any version you target.
Xetius' answer didn't work for me in IntelliJ 14.1.2
In the end I found the section in .idea/misc.xml
<component name="ProjectRootManager" version="2" languageLevel="JDK_1_6" assert-keyword="true" jdk-15="true" project-jdk-name="1.7" project-jdk-type="JavaSDK">
<output url="file://$PROJECT_DIR$/out" />
</component>
I ended up with:
<component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" default="false" assert-keyword="true" jdk-15="true" project-jdk-name="1.8" project-jdk-type="JavaSDK">
<output url="file://$PROJECT_DIR$/out" />
</component>
For me, I needed to go File > Project Structure > Modules. Half of my modules had their "module SDK" field set to the wrong thing (not Project Default as they should have been).

Build Eclipse cross-platform with Maven Tycho

I try to compile an Eclipse Indigo RCP application with Maven and Tycho. It works fine if I just build it for one platform but if I try to build it for more the build stops working.
The Problem is that I have platform specific plugins in my product file I want to build. Dependencies like org.eclipse.swt.win32.win32.x86 which are fragment plugins for org.eclipse.swt.
When I add no platform specific fragments to my product the application wouldn't start because there are no platform libraries like org.eclipse.swt.win32.win32.x86.
As Tycho repository we use a clone of the eclipse indigo update site hosted on our own server. It includes the delta-pack.
And when I add all fragments for all platforms the build crashed and maven tell me that the platform filters did not match for the Linux build for example.
Does anyone know how to fix this?
Should I add these platform dependent stuff into my product? I prefer to keep the specific dependencies out of my product, am I right?
It sounds like you have a plug-in based product. In this case you will need to manually edit your .product file and add in platform filters for these plug-ins. Unfortunately the built-in product editor in eclipse does not expose these values. See http://wiki.eclipse.org/Tycho/FAQ#How_to_build_plugin-based_products_with_platform-specific_fragments.3F
For each plugin e.g. org.eclipse.swt.win32.win32.x86 you will need to add something like;
<plugin id="org.eclipse.swt.win32.win32.x86" fragment="true" ws="win32" os="win32" arch="x86"/>
Note, if you use the product editor it will remove these values.
It is better however to use a feature based product. The feature editor permits these fields to be edited.
There is an easier solution I found in the blog: http://blog.sdruskat.net/building-a-cross-platform-feature-based-eclipse-rcp-product-with-tycho-the-umpteenth/
In the parent/master pom.xml,
To use all the plugins from p2, specify the following:
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>${tycho-version}</version>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<resolver>p2</resolver>
<environments>
<environment>
<os>linux</os>
<ws>gtk</ws>
<arch>x86_64</arch>
</environment>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
</environments>
</configuration>
</plugin>
</plugins>
</build>
My tycho version is 0.21.0