Consider better modularisation of core and eclipse components

[joey-coleman]

Presently many of the ide plugins are built using the dir shape packing scheme, which causes problems occasionally on windows systems due to path length restrictions.

We use the dir shape packing to give access to the various core jars (ast.jar, etc) when we need to run the interpreter (as it runs in an external process). So these jars need to be available directly in the filesystem (and not nested inside another jar).

So, perhaps we should instead pack the plugins into normal jars and have the nested jar files extracted into a designated subdir at activation.

This would entail the activator in ide/core (apparently it's org.overture.ide.core.VdmCore.java, which may not be the best name) look something like:

public class VdmCore extends Plugin
{
    // The plug-in ID
    public static final String OVERTURE_EXTERNAL_JAR_DIR = "somewhere"; 
    ...;
    @Override
    public void start(BundleContext context) throws Exception {
        ...;
        extractJars(OVERTURE_EXTERNAL_JAR_DIR,extractJarsFromBundleClasspath());
        ...;
    }
    ...;
}

Then the stuff we already have to build the external classpath could be adapted to check the bundles they depend on for jar filenames, but build the classpath using the external jar dir.

[joey-coleman]

It looks like we can do this better by using the OSGi Fragment mechanism; splitting the nested jars into a corresponding fragment.

[joey-coleman]

This is now an open question — the current build structure, where we import the core jars directly into the eclipse bundles, has a number of flaws that we are aware of. It would be better if the core jars were imported into the eclipse components in the same sort of manner as any other component, which would vastly simplify the build.