There may still be error in org.openntf.xworlds.core because of the Target Platform. In Window > Preferences, go to Plug-in Development > Target Platform and select "Websphere Application Server Liberty Profile with SPI". Then click OK.
Why and How?
The Target Platform, as for any other plugin development, identifies the platform you want to compile any code that's in your workspace for. When deployed, there will be certain jar files that your code will depend upon. If you're using Maven for configuration will download and copy the jar files, identifying from the configuration specific versions, into your plugin when you build it. But if the code depends on jar files that are already packaged with the server, you don't want to include those in the plugin, but just use configuration to tell the server what they are, which versions and where to find them. That is done in the plugin.xml, on the Dependencies tab. But you still need to compile the code. That's what the Target Platform is for: it identifies which jar files you will have on the server at runtime and where to find them at compile time. The path can be hard-coded or use a variable. The "Websphere Application Server Liberty Profile with SPI" uses a variable - was_liberty_root - which we defined when setting up Eclipse. You may notice we didn't create this. The definition itself is included in the CrossWorlds source code, in org.openntf.xworlds.core - WASLibertyWithSPI.target. As a .target file, it automatically gets made available to the preferences, making it easier for you.
Now everything should be compiled successfully and you are ready to install and enable the feature on Liberty.
Install and Enable
The feature doesn't have a feature.xml file, like an OSGi feature project. Instead it has a SUBSYSTEM.MF file, making it an ESA - an enterprise subsystem archive - when packaged up. The feature can be installed with Eclipse from the feature project itself or via the command line command featureManager install (there are various options you can add to the command, see IBM Knowledge Center help, the same for any Websphere Application Server).
When installing the feature onto the server, the files are physically copied into the usr\extension\lib folder we created when setting up Liberty. This is like installing a feature into Domino Designer via File > Application > Install does - that copies the feature and plugin files into the feature and plugin folders in Notes\Data\workspace\applications\eclipse.
When done from the command line, this copied the files and enables the feature on the server.
When done from Eclipse, the Install Feature option just copies the files to the server. You then need to go to the Feature Manager in the server.xml and enable the feature.
Right-click on the org.openntf.xworlds.features.server project and select Install Feature.... If it says it's already loaded, use Update Feature instead. If you want to confirm, go to the usr\extension\lib folder and confirm the files have been copied. If you're checking in Eclipse, you will need to press F5, to pick up the file structure changes.
Now it needs adding to the Feature Manager. This is done by expanding the server and double-clicking the Feature Manager. In the right-hand side titled "Feature Manager" (you may need to scroll) click Add.... (The Add... button in the left-hand side titled "Configuration Structure" will be greyed out.) Start typing usr to filter. This picks up any user-added features in usr\extension\lib, in this case just CrossWorlds. Select it and click OK.
If you now start the server by right-clicking on it in the Servers view and select Start, the server will start with CrossWorlds contributing OpenNTF Domino API. You can confirm this by seeing Xots start in the console and the server will be accessible on localhost on the port specified in the server.xml, by default port 9080.
You are now ready to begin development or deploy an application that uses CrossWorlds, like OpenNTF Domino API demo database.