product build

[mchlrch]

Installation of JVM, Eclipse and then the editor plugin has shown to be a challenge for a couple of users. Having a single bundle/ZIP with everything included would simplify the install process.

Would be good (but not essential IMO) if we could also show the EULA on the first start of the application.

https://www.vogella.com/tutorials/EclipseProductDeployment/article.html https://wiki.eclipse.org/Building#Cross-platform_build https://www.vogella.com/tutorials/EclipseTycho/article.html

[nnamtug]

Started the product build, see issue_91_product_build.

When it comes to building eclilpse products, there are a lot of pitfalls waiting for you. I'll summarize my findings:

Xtext selecting JDT / non-JDT mode

Xtext is built to run in different environments, for different languages. One of the requirements is to be independent of JDT, if needed. But the way how Xtext checks the availability of Java is also highly impacted by the packaging of all OSGi-Bundles - if anything is not correctly, shipped, you'll get misleading errors like the following: 1) Error injecting method, java.lang.IllegalStateException: Missing contribution for type: org.eclipse.xtext.ui.containers.JavaProjectsState

The error message is not obvious but actually makes sense: If JDT is allegedly disabled, no JavaProjectsState will be registered. 

When packing a product, make sure that Activator.isJavaEnabled() returns the value you need:

public class SharedContributionWithJDT implements Module {

    @Override
    public void configure(Binder binder) {
        if (Activator.isJavaEnabled()) { // <--Activator.isJavaEnagled must be true

And if it does resolve to the correct value, also debug this in the standalone product. The inner eclipse and the standalone product are launched differently, what is likely to impact the result of isJavaEnabled()

An example for strange constellation leading to different results in the inner eclipse compared with the standalone product

isJavaEnabled fals within the standalone product, but true in inner eclipse (depends on target plattform). reason:
    java.lang.NoClassDefFoundError: org/eclipse/xtext/common/types/ui/notification/TypeResourceUnloader

Debugging

For debugging your product:

• start with -console in order to access the OSGi Host console of the product from within the outer eclipse (or shell in standalone case)
• add plugin org.apache.felix.gogo.common in order to get a proper CLI in the OSGi host console
• when getting strange messages like "require capability osgi.service missing", you probably want to add the bundle org.apache.felix.scr . And maybe also org.eclipse.equinox.event
• start with -consoleLog in order to see logs in your launching point (outer eclipse --> console or shell)
• these launch parameters can be set in the product view in the tab "Launching" --> Program Arguments (or in CLI using standalone)

Target Platform

Building a standalone product depends on having a target platform defined. With the TP activated, your dev eclipse will resolve the P2 dependencies on dev time. Unfortunately, most P2 repositories are not reliable - they are replaced by automatic builds, rely on composite structures with sometimes containing dodgy mirror sites. This leads to not only unstable builds, but also to unstable dev-environments. One of the gazillion artifacts (for now it is e.g. com.googl.guice 3.0.0) will not be available anymore. Now you are doomed: you're done developing and shipping. These issues are normally adressed by hosting your own P2 repositories. Means you mirror every dependency in a reliable way. This makes your dev environment and and build pipeline reliable. Doing so probably implies to get an Eclipse Guru on site.

Another example, where composite update sites failed:

Processing inclusion from feature org.eclipse.pde.container.feature: Bundle org.eclipse.xtext_2.18.0.v20190603-1042 failed to resolve.:
    Missing required plug-in com.google.inject_3.0.0.
    Optional plug-in org.eclipse.emf.mwe.core_1.3.21 is not available.
    Optional plug-in org.eclipse.emf.mwe.utils_1.3.21 is not available.
    Optional plug-in org.eclipse.xtend_2.2.0 is not available.
    Optional plug-in org.eclipse.xtend.typesystem.emf_2.2.0 is not available.

How to continue

The basic idea is to help the customer to get its Expressive RDF Workbench up and running fast and stable. What works well in Eclipse is creating new setups using Oomph. We could ship the editor by materializing a new Eclipse, install the XRM-plugin, add the JRE and ship it as a Zip. Not a fancy thing to do, but it works and is reliable.

[mchlrch]

Thanks for investigating and debugging. Let's abandon the Eclipse product build approach for now and keep it simple as you suggested.

ship the editor by materializing a new Eclipse, install the XRM-plugin, add the JRE and ship it as a Zip.